--- title: "Jira sprint carry-over: measure spillover without breaking velocity" description: "Measure Jira carry-over by issues or story points, separate spillover from scope change, and download a CSV calculator for retrospectives." author: "Nemanja Todorović" content_type: GUIDE published: 2026-08-27T10:51:31.200Z updated: 2026-08-27T10:51:31.200Z category: DELIVERY tags: "Jira, Sprint metrics, Carry-over" canonical: /en/blog/jira-sprint-carryover --- # Jira sprint carry-over: measure spillover without breaking velocity A practical way to measure Jira sprint carry-over, separate rolled work from scope change and run a retrospective without turning velocity into a people score. Includes a CSV calculator. ## Key takeaways - Outgoing carry-over and incoming spillover are different metrics and should not be mixed. - Carry-over measures unfinished planned work; ad-hoc work added mid-sprint is tracked separately. - Jira Sprint Report provides the basis for one sprint, while multi-sprint trends require Analytics or your own export. - The metric belongs in retrospectives and planning, not individual performance scoring. The sprint ends, five items are not in `Done`, and Jira asks whether to return them to the backlog or move them into another sprint. Moving them is easy. The harder question is: **how much rolled work is normal, how should it be measured, and does velocity still mean what we think it means?** Carry-over is not proof that a team failed. It is a signal that starting scope and completed scope differ. The cause may be overcommitment, a blocked dependency, an unclear Definition of Done, one oversized item, a production incident or work added after the sprint started. A useful metric helps separate those causes. [Download the Jira sprint carry-over CSV calculator](/jira-sprint-carryover-calculator.csv). Open it in Excel or Sheets, replace the sample values and format the three rate columns as percentages. ## Three numbers you should not mix ### 1. Outgoing carry-over Work that belonged to the starting commitment, was not completed and leaves the sprint unfinished. `carry-over rate = unfinished planned work / starting commitment × 100` If a team planned 80 points and 20 remain incomplete, its point-based carry-over rate is 25%. ### 2. Incoming spillover Work in the current sprint that already appeared in an earlier sprint. `incoming spillover % = work carried from earlier sprints / total current sprint scope × 100` This does not necessarily equal the previous outgoing carry-over. Some items may return to the backlog, be split or receive a new estimate. ### 3. Scope change or ad-hoc work Work added after the sprint started. It may be completed and never appear in carry-over while still consuming capacity that was meant for planned work. Carry-over without scope change can therefore blame planning for a problem introduced mid-sprint. ## Issue count or story points? Item count is easy to audit but treats a one-hour bug like an epic that lasts for weeks. Story points represent relative size better but depend on a stable estimation practice. Use both when possible: - **item rate** shows how fragmented the flow is; - **point rate** shows how much planned scope remained; - **rollover count per item** exposes work dragged through several sprints. Do not add subtask estimates and parent estimates together. Atlassian states that Sprint Report uses estimates on parent work items, not subtask estimates. A team estimating only subtasks will otherwise compare two different measurement systems. ## How to get the data from Jira For a company-managed Scrum board, open **Reports → Sprint Report** and choose a completed sprint. [Atlassian's documentation](https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-sprint-report/) says the report lists completed and incomplete work items, marks items added after the start and depends on the saved filter of that specific board. Check board columns before counting. Jira considers only a status mapped to the right-most board column complete. A misconfigured `Done`, `Canceled` or custom status can create false carry-over. [Atlassian explicitly documents the relationship between column mapping and sprint completion](https://support.atlassian.com/jira-software-cloud/docs/configure-columns/). For every sprint, preserve: 1. starting commitment by item count and points; 2. completed work from that starting commitment; 3. incomplete work moved or returned; 4. scope added after the start; 5. the sprint goal and a short exception note. For multi-sprint trends, Atlassian Analytics offers a `Multiple sprints overview` with commitment, completion, carryover and scope-change metrics. If that is unavailable on your plan, an export and the attached CSV create a simpler audit trail. ## Why changing estimates damages history A common workaround changes an eight-point story to “three points remaining” at sprint close and then rolls it forward. The next sprint looks more precise, but the first sprint no longer retains its original commitment. Velocity and carry-over now use a number that did not exist at the start. A better model preserves three facts separately: - the original estimate; - whether the item finished in its original sprint; - how many times it moved afterward. If the item is genuinely too large, split future work into a newly defined item. Do not rewrite history to make a chart look tidy. ## How to read the trend without scoring people One sprint is not a trend. Review at least three to five consecutive sprints for the same team and ask: - Are the same large items rolling more than once? - Does carry-over rise with ad-hoc work? - Is work accumulating in review or QA? - Do dependencies stay blocked longer than a sprint? - Was the sprint goal achieved even though lower-priority scope remained? The metric becomes harmful when “0% at all costs” becomes a target. A team then reduces commitment, splits items for the statistic or hides scope change. Use carry-over for retrospectives and capacity planning, not developer ranking. ## How WorkThroughLine tracks carry-over When closing a sprint, WorkThroughLine asks what to do with incomplete work items: move them to the next sprint or return them to the backlog. Moving increments a carry-over counter on the item; returning it to the backlog resets the counter. Work added after the sprint starts has a separate ad-hoc marker. The sprint report can therefore show: - how many items finished; - how many rolled over; - how much arrived outside the plan; - which items are moving for a second or third time; - which goals and OKRs the completed work supported. That final point does not replace delivery metrics. It answers a different question: did the delivered scope move something the team said it wanted to achieve? [Compare WorkThroughLine and Jira](/en/vs/jira), [see what the product does today](/en/blog/what-workthroughline-does-today), or start a demo sprint without a credit card. ## Frequently asked questions ### How do you calculate sprint carry-over rate? Divide unfinished planned work at sprint close by scope committed at sprint start and multiply by 100. Use either item count or story points, but keep the unit consistent across sprints. ### Does Jira have a carry-over report? Sprint Report lists completed and incomplete work items and marks work added after the start. A multi-sprint trend is more readily available through Atlassian Analytics or your own export than one standard report. ### Should carry-over be added to the next sprint's velocity? Rolled work consumes next-sprint capacity, but rewriting original estimates damages history. Preserve the starting commitment and show incoming spillover separately. ### What is a good carry-over percentage? There is no universal threshold. Review the same team's trend over several sprints and read it beside scope change, blockers, item size and the sprint goal.