VeloWiseengineering delivery intelligence

Why Work Keeps Carrying Over Between Sprints (and How to Tell Which Reason Is Yours)

A sprint that carries work over once is noise. A team that carries work over every sprint has a system problem, and it is almost never “the team is slow”. This guide separates the six patterns behind persistent carryover so you can fix the one you actually have.

For: Engineering Managers, Team Leads, Directors of Engineering, TPMs, Product ManagersUpdated
Where the unfinished work sitsExample delivery data

Team A · 31 unfinished

Development24
Code review4
QA / testing3

Most unfinished work is still in active development.

Team B · 48 unfinished

Development8
Code review19
QA / testing21

Most unfinished work is already downstream, waiting on review or testing.

Carryover is not automatically an engineering capacity problem — where the unfinished work sits tells you which conversation to have.

How this is calculated: Where the unfinished work sits in the methodology

What persistent carryover is

Carryover is work that was in a sprint when it closed and was not completed, so it moves into the next sprint (or back to the backlog). Persistent carryover is the same thing happening sprint after sprint, often with the same issues. The first is a timing event. The second is a property of how the team plans and works.

The distinction matters because the two need different responses. A single sprint with an incident, a sick week or a surprise dependency will carry work over, and the right response is usually nothing. When carryover is present in five sprints out of six, the plan is systematically larger than what the team delivers, or something inside the sprint keeps consuming the capacity the plan assumed was available.

Carryover in small, multi-role teams

In a larger organisation, testing, support and operations may belong to other teams. In a team of four to eight engineers, the same people build features, fix bugs, test each other’s work, review pull requests, answer support questions and keep production running — often in the same week. Every one of those kinds of work competes for the same capacity, and only some of them were in the sprint plan. That is why carryover in small teams is so often a workload question rather than a speed question.

Why it matters

Persistent carryover compounds. Work that carries in occupies the team before any new work begins, so the next sprint starts with less room than its plan assumes. If the plan does not shrink to match, the next sprint carries over too, and the unfinished pile grows. See WIP debt for how to measure that growth.

It also erodes trust in a way that is hard to repair. Stakeholders stop believing sprint commitments, start asking for dates on everything, and the team spends more time explaining misses than preventing them. Naming the actual pattern — with numbers — replaces that conversation with a planning decision.

“We keep carrying work over” is a symptom. Overcommitment, interruptions, WIP accumulation, testing or review queues and fragmentation are diagnoses — and each has a different fix.

How to tell the six patterns apart

What carryover isExample delivery data

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%

Each pattern leaves a different fingerprint in Jira data. Look across your last six or so closed sprints rather than one, and compare against the team’s own median throughput (completed work per sprint).

PatternFingerprint in the dataInvestigate
A. OvercommitmentWork at sprint start (carryover in + planned new) above median throughput in most sprintsPlanning to requested scope instead of demonstrated delivery
B. Interruptions / scope growthPlanned new work near the median, but effective demand far above it because of work added after startIntake rules and the buffer for unplanned work
C. WIP accumulationThe same issues carrying for 2, 3, 4+ consecutive sprints; recurring carryover risingStale work nobody has decided to split, finish or drop
D. Testing constraintCarried work repeatedly sitting in Testing / QA at sprint closeTesting that batches up near the end of the sprint
E. Review constraintCarried work repeatedly sitting in Code review at closeReview turnaround and WIP limits
F. FragmentationMost engineers handling three or more kinds of work each sprint, with carryover persistingHow many kinds of work the team is asked to juggle at once
Effective demand = planned new work + carryover in + work added after start − work removed
Carryover rate   = carried out ÷ effective demand

Effective demand is the key number. A sprint that planned 40 points of new work can still face 70 points once 20 points carry in and 10 are added mid-sprint. Comparing effective demand with median throughput shows which pile made the sprint too big: the plan itself (pattern A), mid-sprint additions (B) or the unfinished work already in the system (C).

Where carried work was at close

For each carried issue, record the situation it was in when the sprint closed: added in the last days of the sprint, added as a bug or support interruption, blocked, waiting for clarification, in review, in testing, ready for release, still in development, or never started. The distribution of those situations separates patterns D and E from the rest. Status history is needed to know an issue’s stage at close for sprints before the most recent one.

How to interpret what you find

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

An issue that carries once is timing; an issue that carries sprint after sprint is a decision nobody has made.

  • Several patterns at once is normal. Overcommitment and WIP accumulation often travel together: the plan is too big, so work carries, so the next plan starts with carryover it did not account for.
  • Interruptions without overcommitment mean planning is sound but the sprint is not protected. The fix is intake policy and an explicit buffer, not smaller plans.
  • Carryover “still in development” is the least specific situation. If it dominates, look at issue size and at how many kinds of work each engineer handled — see sprint context switching.
  • Carryover “added late” is not a delivery failure. Work added two days before close was never likely to finish; count it separately so it does not distort the picture.
  • Recurring carryover — the same issues, sprint after sprint — is the strongest signal that a decision is overdue.

None of these is a verdict about individuals. Each pattern is a property of how work enters, flows and is planned. The same people in a different system would produce different numbers.

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.

Create Free Account Try sample project

Common mistakes

  • Treating carryover as a velocity problem. Pushing the team to go faster does not help when the plan was 40% above anything the team has ever delivered.
  • Looking at one sprint. A single sprint cannot distinguish a pattern from bad luck. Look at six.
  • Planning new work as if the sprint starts empty. Carryover in is real work; it occupies the team first. See small-team sprint planning.
  • Calling every mid-sprint addition an interruption. Some additions are planned scope arriving late. Group added work by what it is before calling it disruption — see engineering interrupt load.
  • Claiming a cause from a correlation. With a handful of sprints, “sprints with more bugs also carried more” is a pattern worth investigating, not proof.

What to do about each pattern

  1. Overcommitment: plan total demand — carryover in plus new work — to the team’s median throughput, and treat the P75 as a stretch, not a target.
  2. Interruptions: measure how much work usually arrives after planning and reserve that much room explicitly. Agree what leaves when something urgent enters.
  3. WIP accumulation: review every issue that has carried two or more times at planning. Split it, finish it first, or return it to the backlog on purpose.
  4. Testing constraint: move testing earlier and continuously; limit how much work can be “dev done” at once.
  5. Review constraint: set a review turnaround expectation and a WIP limit on open pull requests.
  6. Fragmentation: reduce the number of kinds of work in flight — rotate support duty, batch operational work, or protect some engineers from interrupts for the sprint.

Questions leaders should ask

  • Are we accounting for existing WIP before adding new feature commitments?
  • How much work routinely enters after sprint planning, and do we reserve room for it?
  • Are the same issues repeatedly carrying between sprints — and who decides what happens to them?
  • Are engineers being asked to work across too many categories at the same time?

Example

A six-engineer team carried work over in each of its last six sprints. Planned new work averaged 44 points against a median throughput of 48 — reasonable. But carryover in averaged 18 points and a further 12 points were added after start, so effective demand averaged 74 points. Recurring carryover rose from 1 to 2 to 4 issues across the last three sprints, and in five of six sprints at least four of the six engineers handled three or more kinds of work.

The data pointed to patterns B, C and F, not A. The team kept its planned new work where it was, but started planning *total* demand to the median, reviewed every twice-carried issue at planning, and rotated a single support engineer per sprint. Within three sprints carryover fell below 15% of effective demand.

Related metrics and how the Workload & Carryover report helps

See it on your own data in the Workload & carryover report.

Related guides: Jira carryover, how to reduce sprint carryover, engineering work mix, engineering interrupt load and engineering capacity planning.

The Workload & Carryover report checks all six patterns against your Jira export, shows the rule and numbers behind each, breaks effective demand into planned, carried-in and added work, records where every carried issue was at close, and tracks recurring carryover — with a data-confidence note on every section. Everything runs in your browser.

Frequently asked questions

Why does work keep carrying over between sprints?
Usually because the sprint’s effective demand — planned new work plus carried-in work plus work added mid-sprint — exceeds what the team typically completes, or because work queues in testing or review at the end of the sprint. It is rarely about individual speed.
Is some carryover normal?
Yes. Occasional carryover of a few issues is healthy — it means the team is not sandbagging. Carryover that appears every sprint, or the same issues carrying repeatedly, is the pattern worth fixing.
Can I diagnose carryover from a Jira CSV export?
Mostly. A standard export plus sprint dates shows effective demand, recurring carryover and work mix. Status and Sprint field history make stage at close and added work exact.