Teams don't choose habitual carryover — they slide into it through a cycle that feels reasonable at every individual
step. It starts with a sprint that is slightly overcommitted. One ticket took longer than expected. An external
The dependency wasn't ready. Two tickets carry over. The team notes it in the retrospective, agrees to be more
conservative, and moves on.
The next sprint starts with those two carried-over tickets already on the board. The team plans the new sprint's
scope without reducing it to account for them — after all, they're almost done; they'll be closed by day two. Except
They are not closed by day two because context reloading means they take longer than expected. By the end of
This sprint, two new tickets have been carried over. The cycle has started.
The problem is that most teams have the conversation without the strategy. They diagnose the symptom. We
over-committed — without fixing the upstream decisions that caused it. And so the cycle continues.
This article is about what sprint carryover actually costs. Not in the abstract sense of "it slows you down". In the
concrete, measurable sense of what happens to your team's velocity, your stakeholders' trust, and your developers'
focus, and your product roadmap when carryover becomes a habit rather than an exception.
What Sprint Carryover Actually Is (And What It Isn't)
Let's be precise about what we're talking about, because teams use this term loosely in ways that let them avoid
facing what's actually happening.
Sprint carryover is when work that was committed to in sprint planning is not completed by the end of the sprint and
is moved into the next sprint. That's it. The ticket was in. The team said they would finish it. They didn't.
What it is not: a natural part of agile. A sign that the team is ambitious. An acceptable buffer for complex work.
These are the stories teams tell themselves to make carryover feel less serious than it is.
The real problem with habitual carryover is a loss of predictability and dependability. When your team is
predictable, stakeholders trust you and your work — there is less second-guessing and micromanaging. When
carryover becomes routine, the end of the sprint becomes an arbitrary date, and unfinished work rolls forward
as if it's no big deal.
Except it is a big deal. The data makes that clear.
The Numbers Behind the Problem
Research from Agile Velocity shows that many teams get less than 60% of their sprint plan completed, carrying
over 40% into the next sprint consistently. The goal for Scrum teams should be completing over 80% of
all sprints at 100% of their goal — not delivering 80% of each sprint every time. The distinction matters: a team that
Consistently completing 80% of each sprint is not the same as a team that consistently completes 80% of sprints
cleanly. One is a carryover pattern. The other is reliability.
On the cost side, the numbers are harder to ignore than most teams realise. A Scrum team of around eight
developers, a product owner, and a Scrum Master costs somewhere between $50,000 and $70,000 per two-week period
sprint. When work carries over, that's not free time — you've paid for a sprint that didn't deliver what it committed
to, and now you're paying again for the same work in the next one.
Research suggests developers can lose up to 40% of their productive time to context switching, with each
disruption costing 15 to 30 minutes of recovery time. A carried-over ticket is a context switch built into the structure
of the next sprint. According to research, a single interruption can cost a developer over 20 minutes to regain focus.
the same level of focus — and over a sprint, these pile up into hours of lost time.
The 5 Hidden Costs Nobody Puts in the Retrospective
Teams are good at naming carryover in retrospectives. They are much less good at naming what carryover is
actually costing them. Here are the five costs that consistently go unmeasured.
Cost 1: Lost Context — The One That Compounds Fastest
When a ticket carries over from one sprint to the next, the developer loses something that does not show up
anywhere on the board: context. The mental model of the problem. The decisions made and the reasons behind
them. The edge cases are being considered. The conversation with the product manager three days ago clarified
what "done" actually meant.
Tasks that span multiple sprints tend to become increasingly complex. Information gets outdated, stakeholders
lose context, and the original purpose or urgency of the task can become unclear. The developer now has to
Reconstruct all of this from written notes and ticket comments, which rarely capture everything. Carryover does not
Pause the work. It makes the work harder.
Cost 2: Velocity That Lies to You
Here is a specific and damaging thing that happens to teams with chronic carryover: their velocity number
becomes unreliable. Inflated velocity is far more common than deflated velocity — and if velocity looks higher than
reality, stakeholders are going to have expectations that cannot be met.
Planning future sprints against a velocity number that doesn't reflect reality means every commitment built on that
number carries hidden risk. The estimates feel reasonable because the velocity supports them. The commitments
get missed because the velocity was never real. And the cycle repeats.
Cost 3: A Next Sprint That Starts Behind Before It Begins
A sprint with carryover doesn't start at zero. It starts in deficit. Those carried-over tickets take up capacity that was
budgeted for new work. The team planned the new sprint, assuming they were starting fresh — but they are
carrying forward unfinished work, plus context re-loading cost, plus the psychological weight of entering a sprint
already behind.
This is how carryover becomes structural rather than occasional — not because the team is uncommitted, but
because the planning never fully accounts for the cost of what was brought forward.
Cost 4: Stakeholder Trust That Erodes Quietly
Most stakeholders don't track individual sprint commitments closely. They track whether the things they were told
would be ready are actually ready when they were said to be. When carryover is occasional, it's forgivable. When
It's consistent; something else starts to happen.
The trust damage is slow-building and hard to reverse. Stakeholders start adding buffer to engineering
commitments. Product managers start padding their roadmaps. Engineering estimates become a starting point for
negotiation rather than a reliable signal. Nobody has a direct conversation because no single sprint felt
catastrophic enough to warrant one.
Cost 5: Team Morale That Drops Sprint by Sprint
There is a specific demoralisation that comes from entering a new sprint already carrying work from the last one.
The sprint is supposed to feel like a reset — a clean slate, a clear goal, a defined window of time to do focused
work. When carryover is constant, the reset never happens. The sprint boundary loses its meaning.
A comprehensive study of 1,200 developers across 50 companies found that context switching is driven by carryover
Costs organisations an average of $21,000 per developer annually in lost productivity. For a team of ten
developers, that number is $210,000 a year in value that never shipped.
Table 1 — The 5 Hidden Costs of Sprint Carryover
How Carryover Becomes a Habit (The Cycle Teams Get Stuck In)
Teams don't choose habitual carryover — they slide into it through a cycle that feels reasonable at every individual
step. It starts with a sprint that is slightly overcommitted. One ticket took longer than expected. An external
The dependency wasn't ready. Two tickets carry over. The team notes it in the retrospective, agrees to be more
conservative, and moves on.
The next sprint starts with those two carried-over tickets already on the board. The team plans the new sprint's
scope without reducing it to account for them — after all, they're almost done; they'll be closed by day two. Except
They are not closed by day two because context reloading means they take longer than expected. By the end of
This sprint, two new tickets have been carried over. The cycle has started.
The problem is that most teams have the conversation without the strategy. They diagnose the symptom. We
over-committed — without fixing the upstream decisions that caused it. And so the cycle continues.
What the Pattern Looks Like From the Outside
A product manager is preparing a roadmap update for a leadership review. Three features were supposed to ship
in Q2. Two of them are now in their fourth sprint of carryover. They were "almost done" six weeks ago. They are
still "almost done".
The engineering team commits to closing both, plus three new tickets, because those are also important. The
A sprint starts with five items of genuine priority and capacity for maybe three. Two tickets carry over. The roadmap
slips to Q3. The leadership review becomes a conversation about why engineering is behind.
Nobody in this scenario was dishonest or uncommitted. The pattern created the outcome. And the pattern started
With one sprint's carryover being treated as a minor administrative task rather than a signal that the planning
The system had a problem worth fixing.
Table 2 — Carryover Signals by Sprint Week
How to Break the Carryover Cycle
The good news about sprint carryover is that it's fixable—not through heroics or longer hours, but through three
Specific changes to how sprints are planned and monitored.
Fix 1: Treat Carryover as a Planning Error, Not a Delivery Error
When work carries over, the problem is almost always in the planning, not the execution. The ticket was brought
into the sprint before it was truly ready. The capacity was overestimated. A dependency wasn't confirmed. If the
retrospective conversation is "we need to work faster," you're solving the wrong problem. The conversation should
be: what did we know during planning that should have told us this ticket wasn't ready to commit to?
Teams can help avoid carryover by filling only 75% of their capacity in sprint planning, splitting work into smaller tasks
pieces of value, and updating the sprint backlog as soon as they learn a ticket cannot be completed that sprint.
Fix 2: Give Carryover Tickets a Different Status on Day One
They're lower priority, but because they carry context risk and reconstruction overhead that new tickets don't.
Assign a developer to them specifically on day one. Make closing the carryover the explicit priority before new
work begins.
"Later" is how carried-over tickets from sprint four end up in sprint seven.
Fix 3: Act on Carryover on Day One — Not Day Eight
The most expensive thing about carryover is not the work itself. It is the delay between when the carried-over ticket
enters the new sprint and when someone actually makes a decision about it. Most teams notice it, move on with
the sprint, and deal with it "once the new tickets settle." That delay is where carryover turns from a one-sprint
Inconvenience into a multi-sprint pattern.
This is exactly where Spryn (spryn.io) changes the dynamic. When you open the sprint on day one, carry over
Tickets are already visible on the sprint screen — flagged, with their history, right next to everything else. You don't
open a separate report or pull up the last sprint's board. The context is there, and so is the action. Reassign it, adjust
the scope, move something out — all from the same screen, before standup, before the new sprint has had a
chance to absorb the cost quietly. The decision happens when it is still cheap to make it.
Table 3 — Carryover Prevention Checklist
The Conversation Most Teams Never Have
In many teams, carryover is treated as a neutral event — something that happened, noted in the retrospective,
moved forward. The language around it is careful. "The ticket spilled over." "We didn't quite get to it." "It's almost
done, it'll close in the first day or two."
This language makes carryover feel acceptable. It treats a commitment that wasn't met as a scheduling event
Rather than a signal that the planning system produced an outcome it was supposed to prevent.
The teams that break the carryover cycle are the ones that have stopped using soft language for it. Not to create blame
— but to create honesty. "We committed to this and didn't deliver it. What specifically made that commitment wrong
from the start?" That question, asked genuinely and without defensiveness, produces improvements. "We'll do
better next sprint" doesn't.
Questions Teams Ask About Sprint Carryover
Is some carryover normal? Are we being too hard on ourselves?
Occasional carryover is part of working in a complex, unpredictable domain. One ticket carrying over in an
otherwise clean sprint is not a crisis. The problem is when carryover is consistent — when it happens in most
sprints, when the team expects it, and when carried-over tickets become a permanent fixture at the top of the board. At
that point, it's not bad luck — it's a system producing a predictable output, and the system needs to change.
Should we count carried-over work in the original sprint or the sprint it closes in?
Neither option is clean, and that's the point. Inflated velocity is far more common than deflated velocity, and
stakeholders will have expectations that cannot be met. The most honest approach is to track carryover separately
as its own metric — measure it sprint over sprint and treat an upward trend as a planning health signal, not a
delivery health signal.
The team works hard every sprint. Why does carryover keep happening?
Because carryover is rarely a work ethic problem. Teams commit to work without a clear, shared view of
real capacity — not theoretical capacity, not ideal capacity, but real, usable capacity. When that gap exists,
carryover is the output. The fix is in the planning, not in asking the team to work harder against a commitment that
was unrealistic before the sprint started.
How does Spryn help with carryover specifically?
The honest answer is that most tools don't make carryover feel urgent — it just shows up on the board and blends
in with everything else. By the time someone explicitly addresses it, the sprint has already absorbed the cost. With
Spryn (spryn.io), carried-over tickets are visible on the sprint screen from the moment the sprint starts — flagged,
with context, sitting right there next to the new work. There's no separate view to open, no report to generate. You
see it, you decide what to do about it, and you do it from the same screen. Whatever the right call is, it happens
before standup on day one, not after standup on day nine.
What Clean Sprints Actually Feel Like
It is worth describing what the alternative looks like, because teams that have been in a carryover cycle for a long time
enough sometimes forget.
A clean sprint — one that closes without carried-over work — does not mean a sprint where everything was easy.
It means a sprint where the commitment was honest, the tickets were ready, the scope was protected, and the
team made explicit decisions when something unexpected came up, rather than hoping it would sort itself out by
Friday.
Clean sprints produce something that chronic carryover erodes: a genuine sense that the team is moving. Each
sprint starts with a real reset. The sprint goal means something because the team has demonstrated it can achieve
one. Stakeholders start trusting estimates. Developers start entering sprints with energy rather than the familiar
weight of unfinished business from the sprint before. That is what execution actually feels like when the planning
system is working.
Tired of starting every sprint already behind?
Spryn is built for teams that want carryover to be a decision, not a default. Carried-over work is visible on the sprint screen from day one — with context, with history, and with the action right there. No reports to open. No dashboards to cross-reference. Just a clear view of what needs a decision and the ability to make it before it costs you another sprint.