How to Reduce Sprint Carryover: A Playbook for Engineering Managers
Carryover rarely falls because a team tries harder. It falls when the commitment matches historical delivery, when work is small enough to finish, and when the stage that is actually holding work gets attention.
Team A · 31 unfinished
Most unfinished work is still in active development.
Team B · 48 unfinished
Most unfinished work is already downstream, waiting on review or testing.
Reducing carryover starts with where it sits: development, review, testing and release each need a different fix.
How this is calculated: Where the unfinished work sits in the methodology
What "reducing carryover" really means
The goal is not zero carryover. A team with no carryover for months is usually committing too little. The goal is carryover that is small, stable, and explained — typically a few issues each sprint, for reasons the team understands.
If you have not yet measured carryover and its reasons, start with measuring Jira carryover. The playbook below assumes you know roughly where unfinished work sits at sprint close.
Why it is worth the effort
High carryover makes every downstream plan less reliable, and it compounds: old work consumes the next sprint's capacity before any new commitment is made. Teams stuck in a carryover spiral often feel busier than ever while shipping less, because more work is in progress at once and each item waits longer in every queue.
Step 1 — Diagnose before acting
Sprint 10 · at close
- Issue ADone
- Issue BQA / testing
- Issue CCode review
- Issue DDevelopment
Sprint 11 · starts with
- Issue BCarryoverwas in QA
- Issue CCarryoverwas in code review
- Issue DCarryoverwas in development
- Sprint 10 scope
- 20
- Completed
- 17
- Carryover
- 3
Carryover rate = carried over ÷ sprint scope = 3 ÷ 20 = 15%
Break carryover down three ways before choosing an intervention:
| Breakdown | Question it answers |
|---|---|
| By stage at close | Where is unfinished work sitting? (dev, review, QA, release, blocked, not started) |
| By origin | Was it original commitment, added mid-sprint, or already carried in? |
| By age | How many sprints has it been rolling? Repeat carryover is a different problem. |
Each pattern maps to a different fix. Applying the wrong one — for example adding developers when work is waiting on QA — makes things worse.
Step 2 — Match the fix to the pattern
One-time carryover — carried once, then finished
- Sprint 10
- Sprint 11
Chronic carryover — carried three sprints in a row
- Sprint 8
- Sprint 9
- Sprint 10
- Sprint 11
An issue that carries once is timing; an issue that carries sprint after sprint is a decision nobody has made.
| Pattern | Likely cause | Intervention |
|---|---|---|
| Many "not started" at close | Over-commitment | Commit within the historical throughput range |
| Stuck in code review | Review capacity, large PRs | Review-before-new-work norm, smaller PRs, review rotation |
| Stuck in QA / late QA arrivals | QA capacity, late hand-offs | Finish dev earlier, developers help verify, test automation |
| Ready for release | Release cadence | Release more often; separate deploy from release |
| Blocked | External dependencies | Confirm dependencies in refinement; escalate early |
| Waiting on clarification | Refinement quality | Acceptance criteria before commitment |
| Repeat carryover (3+ sprints) | Issue too big or unclear | Split or re-scope; question whether it is still needed |
Most teams find one or two patterns account for the majority of unfinished work. Resist the temptation to address all seven at once: every process change has a cost, and changing several things in one sprint makes it impossible to tell which one helped. Pick the pattern that holds the most unfinished issues, make one change, and give it two sprints before judging it.
Account for carryover before committing new work
Carryover reduces the next sprint’s capacity before planning starts. A team that completes a median of 50 points and carries 30 points forward has room for about 20 points of new work in a typical sprint. When planning ignores this, the new sprint starts overloaded, carries over again, and the pattern compounds. Put carried-in work first in planning, decide explicitly whether each item is finished, split or returned to the backlog, and only then size new commitment. See sprint commitment vs capacity.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Pushing harder at the end of the sprint. It moves work into QA on the last day, which is exactly where it then gets stuck.
- Starting more work to "keep people busy". More work in progress means longer queues and more carryover. See aging WIP.
- Committing the same amount after a bad sprint. Plan against what happened, not what was hoped for.
- Fixing the loudest symptom. Fix the stage that holds the most unfinished work.
Step 3 — A four-sprint plan
- Sprint 1: Plan carried-in work first and commit new work only up to the historical median. Record why each issue carries over.
- Sprint 2: Address the single largest carryover stage with one concrete change (e.g. a daily review slot, or QA pairing in the second week).
- Sprint 3: Split every issue that has carried over twice. Introduce a WIP limit per person or per stage.
- Sprint 4: Compare carryover rate and reasons with the baseline. Keep what worked; drop what did not.
Use the commitment simulator to check each plan against historical delivery before the sprint starts.
Two policies that prevent most carryover
A definition of ready. An issue enters a sprint only when it has acceptance criteria, known dependencies and a size the team believes fits comfortably inside the sprint. This removes the clarification waits and blocked time that turn into carryover later.
Stop starting, start finishing. When someone finishes a task, the first question is whether they can help move an existing item forward — a review, a test, a release — before pulling new work. It feels slower for a day and is noticeably faster by the end of the sprint.
Example
A team's carryover rose from 17% to 55% over three sprints. The stage breakdown showed 11 of 17 carried issues sitting in code review at close, with median review time up from 1 to 3.5 days — two senior reviewers were on leave. The team agreed that nobody starts new work while a review older than one day is waiting, and paired junior reviewers with seniors. Review time and carryover both fell in the next sprint, without adding anyone.
How this tool helps
See it on your own data in the Carryover report report.
The Sprint Forensics view reconstructs what happened in each sprint and ranks the contributing factors present in unfinished work, and the carryover analysis shows reasons with evidence labels. Both run entirely in your browser.
The Capacity & Commitment report shows how much of each sprint’s commitment was carryover, whether carryover is rising, and how existing WIP compares with historical delivery when you plan the next sprint.
Frequently asked questions
- What is a good sprint carryover rate?
- Stable teams often carry over 10–20% of sprint scope. More important than the level is that it is stable and the reasons are understood.
- Should carried-over issues be re-estimated?
- Keep the original estimate for measurement. If you want a remaining-work estimate for planning, record it separately so historical data stays comparable.
Related guides
Sprint carryover
How to calculate sprint carryover from a Jira export, classify it by reason (review, QA, release, blocked), and tell the difference between observed and inferred causes.
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.
Engineering capacity planning
A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.
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.