Sprint Carryover: Understand Why Work Keeps Moving Between Sprints

What carryover is

Carryover (also called spillover or rollover) is any issue that was in a sprint when it closed without being completed, and so moved to a later sprint or back to the backlog. In Jira, carryover is visible because the Sprint field keeps every sprint an issue has been in: an issue that appears in "Sprint 14" and "Sprint 15" carried over from 14.

It helps to separate two directions:

• Carried out — unfinished at the close of this sprint.
• Carried in — work that entered this sprint from an earlier one. This is the WIP debt the sprint started with.

Why carryover matters

A Jira sprint report identifies incomplete work and scope changes. To explain why stories carry over between sprints, connect that report with stage-at-close evidence, repeated carryover, dependencies and the capacity assumed at planning. A carryover percentage alone cannot choose the right intervention.

Carryover compounds. Each unfinished issue consumes capacity in the next sprint, but planning rarely accounts for it fully — teams commit new work "on top". The next sprint then carries over more, and within a few sprints a large share of every sprint is old work.

Carryover also hides where the constraint is. Twelve carried-over issues sitting in code review is a review-capacity problem. Twelve sitting in "Ready for Release" is a release-cadence problem — the engineering work is done. Treating both as "the team didn't finish" leads to the wrong fix.

How to calculate carryover from Jira

Carryover rate = issues unfinished at sprint close ÷ issues in the sprint at close

Calculate it for issues and points. From a standard CSV export, an issue carried out of sprint S if it lists a later sprint in its Sprint field and was not resolved inside S. With sprint dates, "resolved inside S" can be checked against the Resolved date; without them, Jira's own behaviour (it only moves unfinished issues) is a reasonable inference.

Classifying carryover by reason

The reason is the stage the issue was in at sprint close: still in development, in code review, in QA, blocked, waiting on clarification, ready for release, or never started. Here the data quality matters:

Presenting an inferred or unknown reason as fact is the most common way carryover reports mislead. Label the evidence.

How to interpret carryover

Engineering carryover versus release carryover

Engineering carryover still needs development, code review, testing or clarification. Release carryover has passed the team’s engineering checks but awaits deployment or a release decision. Show both counts alongside the agreed definition of done. A release-ready label alone is not proof that every engineering check passed.

Blocked work may depend on another team or supplier. Track external dependency ownership separately from workflow stage; it can overlap QA or development. Requirement clarification, QA rejection, reopened work and discovered edge cases are investigation signals. Confirm requirement-driven rework with history and discussion before calling it a cause.

• There is no universal healthy carryover percentage. Compare your team’s trend with work size, release cadence and definition of done. Zero carryover alone is not evidence of under-commitment.
• Rising carryover over three or more sprints means the system is not recovering — planning is not adjusting to reality.
• Repeat carryover (issues in three or more sprints) usually means the issue is too large, blocked, or unclear. It rarely means the team is slow.
• Carryover concentrated in one stage points at a constraint. See engineering bottlenecks.
• Carryover dominated by "not started" means the sprint was over-committed from day one.

Common mistakes

• Counting only points. Unestimated bugs and tasks disappear from point-based carryover.
• Treating release-ready work as unfinished engineering. It needs a release decision, not more developers.
• Guessing reasons from current status for old sprints. Without history, the reason is unknown — say so.
• Re-estimating carried issues downward so velocity looks better. It hides the size of the problem.
• Blaming individuals. Carryover is a property of the system — commitments, queues and dependencies.

What to do about it

1. Plan the next sprint with carried-in work counted first, then add new work up to the historical range. The commitment simulator does this arithmetic.
2. Fix the largest carryover reason first. One stage usually dominates.
3. Split issues that have carried over twice. Repeat carryover is a size or clarity signal.
4. Separate "done, not released" from engineering carryover in status reports.
5. Read the practical playbook: how to reduce sprint carryover.

Example

Sprint 16 closes with 23 of 28 issues unfinished (82%). A percentage-only report would call it a disaster. The reason breakdown tells a different story:

Most of the "carryover" was finished engineering work held by a release freeze. The action is a release-process conversation, and the next sprint's real engineering load is much smaller than 23 issues suggests.

How this tool helps

See it on your own data in the Carryover report report.

The carryover analysis calculates carried-in and carried-out rates, repeat carryover, and a reason breakdown with each issue labelled Observed, Inferred or Unknown. Import a change-history file to turn inferred reasons into observed ones. Signed-out imports stay in this browser; organization imports are stored for your team. Read the data-handling guide.

Frequently asked questions

How do I find carryover in Jira?

Export issues with the Sprint field. Jira writes one Sprint column per sprint an issue has been in, so an issue listing more than one sprint carried over from the earlier ones.

What is WIP debt?

The unfinished work a sprint inherits from earlier sprints. It consumes capacity before any new commitment is made, which is why it should be planned first.

Why can’t the reason for older carryover be determined from a CSV?

A CSV export only contains each issue’s current status. Where an issue was at the end of a sprint several weeks ago can only be reconstructed from its status change history.

Related guides

• Reduce carryover

  A practical, evidence-first playbook for reducing sprint carryover: diagnose by stage, right-size commitments, limit WIP, and fix the constraint instead of pushing harder.

• Commitment vs capacity

  Why sprint commitments drift above team capacity — carryover, existing WIP, scope growth — how to measure commitment accuracy without turning it into a performance metric, and how leaders can plan to demonstrated delivery.

• Sprint health

  A practical guide to sprint health for engineering managers: commitment reliability, scope change, carryover and throughput — how to calculate them from Jira and what to do about them.

• Engineering bottlenecks

  How to find delivery bottlenecks in an engineering workflow using queue size and time-in-stage, why arbitrary red/amber/green thresholds mislead, and what to do once you find the constraint.