VeloWiseengineering delivery intelligence

Why Work Carries Over Between Sprints

Carryover — work that was in a sprint and did not finish — is usually reported as a count. “36 issues carried over.” The count is accurate and almost useless on its own. What leadership needs to know is where that work was, and whether it is the same work as last time.

Part of Engineering Delivery Intelligence: better planning and fewer surprises

For: Engineering managers, directors and delivery leadsUpdated

This guide answers

  • Where was the unfinished work when the sprint ended?
  • Is carryover a planning, flow or dependency problem?
  • Which work keeps carrying, sprint after sprint?
  • What should change next sprint?

A count vs a context

Sprint 24 · reporting carryoverExample delivery data

The count

36 issues carried over

  • Sounds like 36 of the same problem
  • Usually read as “engineering didn’t finish”
  • Gives no hint of what to change

The context

18 of 36 were past development

  • 6 never started — planning
  • 8 still in development
  • 7 in code review, 11 in QA — flow
  • 4 blocked — dependencies

The count says how much. The stages say why, and who can fix it.

Carryover is not automatically a sign that engineers worked slowly. In many teams most carried-over work has already left development: it is waiting for a reviewer, a test environment, a tester or a release window. Counting it as “not done” is correct; reading it as “engineering underdelivered” usually is not. Telling waiting from active work needs a workflow with explicit queue states — see active vs waiting work in software delivery workflows.

Carryover by delivery stage at sprint close

Sprint 24 · where the unfinished work was when the sprint endedExample delivery data
  • Not started6planning
  • Development8size, interrupts
  • Code review7review capacity
  • QA11testing capacity
  • Blocked4dependencies

Also: 8 issues were done but not released. They carry over only if your definition of done is “in production”.

Each stage points at a different owner and a different fix.

Stage at closeWhat it usually meansWho can act
Not startedThe sprint was over-planned, or work was displaced by additionsPlanning: product and engineering together
DevelopmentWork was larger than expected, or interruptedThe team: split work, protect focus
Code reviewReviews wait for reviewers; work is started faster than it is reviewedThe team: review before starting new work
QATesting capacity or environments are the constraintEngineering leadership: testing capacity, automation
BlockedWaiting on another team, a decision or an external partyLeadership: escalate the dependency
Done, not releasedRelease process or approval is the constraintRelease owners: cadence and gates

The important detail is when the stage is measured. Use the status each issue had at the moment the sprint ended, reconstructed from its history. By the time someone looks at the report, many of those issues will have moved on — and their current status will make the sprint look better or worse than it was.

Status at sprint close vs current statusExample delivery data
  1. Sprint 10 endsABC-123Code review
  2. Sprint 11 startsABC-123Carryover
  3. TodayABC-123Released

Historical carryover analysis

Why did Sprint 10 carry this over?

Status at sprint close = Code review

Current sprint analysis

Where is our inherited work now?

Current status = Released

Report the stage at sprint close. Today’s status describes today, not why the sprint ended the way it did.

Chronic carryover: the same work, sprint after sprint

One-time vs chronic carryoverExample delivery data

One-time carryover — carried once, then finished

  1. Sprint 10
  2. Sprint 11

Chronic carryover — carried three sprints in a row

  1. Sprint 8
  2. Sprint 9
  3. Sprint 10
  4. Sprint 11

One-time carryover is normal. Work that carries three or more times is a decision nobody has made.

One issue’s path · Sprints 20 to 23Example delivery data
  1. Sprint 20Committed; reached development
  2. Sprint 21Carried over; waited in code review
  3. Sprint 22Carried over; back in development after review
  4. Sprint 23Carried over; blocked on an API change
Issues carried 3+ sprints in Sprint 24
6

Four sprints in, the issue has consumed planning time in every one of them and still is not delivered.

Most carryover resolves in the next sprint. A small number of issues do not: they carry three, four, five times. In Sprint 24, 6 issues had carried across three or more sprints. Each one reappears in every planning session, takes up space in the commitment, and makes the team look less reliable than it is.

Chronic carryover almost always needs a decision rather than more effort: split the work, unblock the dependency, or deprioritize it explicitly. Leadership can often make that decision in minutes once it is visible.

The common reasons behind carryover

  • Overcommitment. The plan exceeded demonstrated throughput before the sprint began. See commitment vs completion.
  • Mid-sprint additions. New work displaced planned work. See how scope change affects outcomes.
  • Downstream queues. Work finishes development faster than it is reviewed, tested or released. See finding delivery bottlenecks.
  • Dependencies. Another team, a vendor or a decision holds the work.
  • Large or unclear work. Issues that are too big to finish in a sprint, or that change shape as they are built. See requirements quality.

Most sprints have more than one of these at once. The stage breakdown tells you which is largest this time, and the trend over several sprints tells you which is persistent.

Explaining carryover to leadership

Example · Sprint 24 carryover

36 issues carry into Sprint 25. 18 of them are past development — 11 in QA and 7 in code review — so most need testing and review time, not new engineering.

4 are blocked on the payments API change (escalated). 6 were never started after mid-sprint additions displaced them.

6 issues have now carried three or more sprints; we propose splitting two and deprioritizing one.

The message names where the work is, what it needs, and the decisions leadership can help with. The engineering status report guide shows how carryover fits into a complete sprint update.

See this in VeloWise: Carryover and WIP debt

Unfinished work by delivery stage at sprint close, carryover trends, and the issues carried across several sprints — with their original sprint.

Open Carryover and WIP debtHow carryover and wip debt works

Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.

Go deeper

Frequently asked questions

How much carryover is normal?
Some carryover is normal in most teams, especially with a strict definition of done. Watch the trend, the share of carryover past development, and the number of issues carrying three or more times.
Does carryover mean the team underperformed?
Not by itself. Much carryover sits in review, QA or release, or was displaced by added work. The stage at sprint close shows which.
Should carried-over work be re-estimated?
It helps to re-check it at planning: the remaining work is often smaller (it is past development) or larger (it was blocked). Planning it at its original size distorts the next commitment.

All engineering delivery guides