Your Scrum Carryover Problem Is Probably Not a Carryover Problem
Unfinished sprint stories are usually a symptom of deeper flow, sizing, WIP, or Definition of Done problems.
At the end of the sprint, the board often tells the real story.
A few tickets are done.
A few are in code review.
One is waiting for QA.
Another is stuck in product review.
Something is “basically done, just needs release.”
Should we just move these to the next sprint?
Most teams do exactly that.
They drag unfinished stories into the next sprint, maybe adjust the dates, maybe keep the same estimate, and continue as if nothing important happened.
But something important did happen.
The sprint gave you a signal. 🚦
The goal is not to become better at moving unfinished stories.
The goal is to make unfinished work:
rare
visible
small
intentionally handled
✅ First, be honest about “done”
A story is not done because the coding is done.
If a story is still in code review, QA, product review, release, or waiting for validation, it is not done unless your team’s Definition of Done clearly says otherwise.
“Almost done” is not done.
“Dev complete” is not done.
“Only QA left” is not done.
“Just waiting for release” is not done.
This may sound strict, but it matters.
A sprint should measure finished, usable work, not effort spent.
If an 8-point story is 90% done at the end of the sprint, the team completed 0 points for that story in that sprint.
Not 4.
Not 6.
Not “let’s count half.”
Zero.
Partial credit feels harmless, but it damages the signal. Velocity becomes fiction. Planning becomes optimistic. Retrospectives become polite storytelling.
If the work does not meet the Definition of Done, it is unfinished.
🔁 The worst habit: automatic carryover
The most dangerous version of carryover is the quiet one.
Nobody discusses the story.
Nobody asks why it did not finish.
Nobody checks whether it was too large.
Nobody challenges the original plan.
It just moves.
That is how teams normalize unfinished work.
At sprint end, every unfinished story should be reviewed intentionally.
For each item, ask:
Should we carry this over as one coherent story?
Should we split the done part from the remaining work?
Was this story too large from the beginning?
Do we need to re-estimate the remaining work?
What did this reveal about our process?
The point is not to blame anyone.
The point is to stop losing information.
Every unfinished story is a small retrospective waiting to happen.
🔍 Why stories usually roll over
In my experience, recurring carryover usually comes from a few predictable places.
1. Stories are too big
Many “stories” are actually small projects.
They include backend changes, frontend changes, review, QA, product validation, release work, tracking, documentation, edge cases, and maybe coordination with another team.
Then everyone is surprised when the story does not finish in one sprint.
A useful rule:
Most stories should be finishable in 2–3 days of active work.
Not because 2–3 days is magical.
Because small stories expose problems earlier. Large stories hide risk until the end.
Instead of slicing work like this:
Build booking API
Build booking UI
Test booking flow
Slice it around user-visible progress:
User can view available times
User can select a time and submit a booking
User receives a booking confirmation
Admin can see the booking in the dashboard
That kind of slicing gives the team more chances to finish real value.
2. Too much work starts too early
A board with many columns can create a false sense of progress.
Todo.
In Progress.
Code Review.
QA.
Product Review.
Release.
Done.
It looks organized.
But if many items are spread across those columns, the team may be starting too much and finishing too little.
That is not delivery.
That is inventory. 📦
Work sitting in review is inventory.
Work waiting for QA is inventory.
Work waiting for product validation is inventory.
Work waiting for release is inventory.
Inventory gets stale. Context disappears. Merge conflicts appear. Acceptance criteria get reinterpreted.
The team feels busy, but value is not landing.
A better daily question is not:
What am I working on?
It is:
Which item is closest to done, and how do we finish it today?
3. Planning is based on coding capacity, not completion capacity
This is one of the most common mistakes.
During sprint planning, teams often ask:
How much can we build?
The better question is:
How much can we finish end-to-end?
Those are very different questions.
A story does not only need implementation. It also needs review, testing, acceptance, and whatever your Definition of Done requires.
If review, QA, product validation, or release is constrained, that is the real capacity limit.
Ignoring that limit does not make the team faster. It just creates more unfinished work.
If 25–30% of work usually rolls over, the answer is not a motivational speech about commitment.
The answer is simple:
Plan less until completion stabilizes.
Overcommitting is not ambition. It is bad forecasting.
A team that finishes 70% of planned work every sprint is not more ambitious than a team that plans realistically and finishes consistently.
It is just generating noise.
4. The Definition of Done is unclear
Many teams use the word “done” without agreeing what it means.
Does done mean merged? QA passed? Accepted by product? Released to production? Production-ready behind a feature flag?
There is no universal answer. But there must be a team answer.
A useful Definition of Done might include:
code is complete
code review is complete
tests are added and passing
QA is complete
product acceptance is complete
deployment or agreed release state is complete
documentation, tracking, and feature flags are handled where relevant
The exact list depends on the team.
But ambiguity is expensive.
If “done” means one thing to engineering, another thing to QA, and another thing to product, unfinished work will keep piling up at the edges.
5. The team optimizes for starting, not finishing
Near the end of the sprint, many teams still behave like a group of individuals.
One developer starts a new story. Another waits for review. QA is overloaded. Product has three items to check. The board is full of nearly finished work.
This is where the team needs to swarm. 🐝
At some point, the question should stop being:
What is my task?
And become:
What can we finish together?
That may mean reviewers prioritize reviews over new coding. Engineers help reproduce QA issues. Product reviews happen earlier. Someone pairs on the oldest blocked item.
This is not less efficient.
It is often the fastest path to actual delivery.
Starting more work while existing work is stuck is usually just a way to look busy.
🧭 A better carryover policy
If a team has recurring carryover, I would start with a simple working agreement.
At the end of the sprint:
Every unfinished story is reviewed one by one.
If it does not meet the Definition of Done, it is unfinished.
Unfinished stories get 0 completed points in that sprint.
No story is moved automatically.
Each unfinished story is either intentionally carried over, split, or reworked before the next sprint starts.
Carryover is made visible and discussed in the retrospective.
If the story is almost done and still one coherent item, carry it over intentionally.
Mark it as carryover. Do not count its points in the previous sprint. Discuss it during next sprint planning.
If the story contains a truly finished part and a remaining part, split it.
But be careful: the finished part must be independently valuable and meet the Definition of Done. Otherwise, it is not finished. It is just a comforting explanation.
If the story was too large from the beginning, do not carry the oversized story as-is.
Split it before the next sprint starts.
🛠️ The practical fix
I would not start with a big process transformation.
I would start with four changes.
1. Make stories smaller
Most stories should be finishable in 2–3 days of active work.
Any story likely to span most of the sprint should be split before the sprint starts.
2. Define Done clearly
Decide whether done means deployed to production, production-ready behind a feature flag, or something else.
But decide.
3. Limit work in progress
Especially in:
In Progress
Code Review
QA
Scrum teams can still use Kanban flow practices. There is no law against being practical.
4. Plan from historical completion, not optimism
Look at what the team actually finished in previous sprints.
Include review, QA, product availability, release constraints, meetings, support work, vacations, and interruptions.
If a team usually rolls over 25–30% of the sprint, reduce planned scope until completion becomes stable.
That may feel uncomfortable.
Good.
The discomfort is the old process telling you the truth.
⚠️ Anti-patterns to avoid
A few habits make carryover worse:
moving unfinished stories automatically
keeping giant stories alive across multiple sprints
giving partial points for incomplete work
starting new work while review or QA is overloaded
treating “code complete” as done
changing Scrum ceremonies while keeping old batching and handoff behavior
That last one is common.
Some teams adopt Scrum meetings but keep waterfall-style behavior inside the sprint.
That is not agility.
That is waterfall in two-week costumes.
🎯 The point
Carryover is not always bad.
Real things happen. Dependencies appear. Production incidents interrupt the sprint. A story reveals hidden complexity. A product decision changes.
That is normal.
But if carryover is common, predictable, and treated as routine, the team should stop asking how to move unfinished stories more efficiently.
Ask why so many stories are unfinished in the first place.
A sprint should be planned around finishing small, end-to-end valuable stories.
Not around starting many stories and hoping they somehow reach Done before the calendar runs out
