Work keeps carrying into the next sprint? Investigate before changing the estimate
Tech at Work Series
The sprint ends, unfinished work moves forward, and somebody suggests increasing the estimates next time. That might change the numbers without explaining what happened.
When work repeatedly carries over, investigate the story behind it. Was the item larger than expected? Did an urgent request interrupt it? Was the team waiting for a decision? Different causes need different responses.
This guide offers a small retrospective exercise. A retrospective is a team conversation about improving how the work happens. The aim here is to agree one useful change based on evidence from recent work.
Understand what happened to the work
1. Separate the goal from the item count
Purpose: Understand both the Sprint Goal outcome and the unfinished work.
Begin with two questions: did the team achieve the Sprint Goal, and which selected items remain unfinished? These are related observations, but they tell you different things.
A sprint might achieve its intended outcome while an additional item remains incomplete. Another might finish several tickets while missing the outcome that mattered. Record both before deciding what needs attention.
In Scrum, unfinished work returns to the Product Backlog for future consideration. It should not automatically become the next sprint’s highest priority. Reconsider its value and what remains with the Product Owner and Developers.
Do not mark incomplete work as Done to improve a report. The Definition of Done is the shared description of the quality measures required for the product. If the work does not meet it, a percentage-complete label does not make it a usable result.
2. Follow three items through the sprint
Purpose: Reconstruct what changed and where the work waited.
Choose three recent unfinished items as a starting sample. Include completed work for comparison if that would help. A small sample is a discussion aid, not enough to prove a team-wide pattern.
Use the board history, relevant messages and the team’s account to establish what happened. Capture missing information as unknown rather than filling gaps with guesses.
- What was understood when the item was selected?
- When did active work begin?
- What changed after it began?
- When was it waiting, and for what?
- What work is still required to meet the Definition of Done?
- What could the team influence, and what needs help elsewhere?
Keep the focus on the work and its conditions. Individual rankings rarely explain a shared dependency or conflicting priorities.
Turn the evidence into an experiment
Worked example: three carry-overs, three different causes
Purpose: Explore why similar outcomes can have different causes.
This is a fictional teaching example.
A notification preference change expanded when the team discovered that two systems held conflicting settings. A reporting change waited for somebody to confirm a calculation. A small export improvement stopped when the team responded to an operational incident.
Calling all three “poor estimation” hides the useful detail. The first suggests an uncertainty that might need investigating earlier. The second suggests a decision was needed before implementation could proceed. The third requires an honest discussion about interruptions and available capacity.
The team chooses to tackle the repeated calculation issue first because similar questions have delayed several recent items. They agree to confirm calculation examples before selecting the next related reporting change.
They also record the incident response so the next planning conversation reflects the work the team actually did. They do not assume that incidents can be eliminated or predict their timing precisely.
Run a 25-minute investigation
Purpose: Agree one useful change based on evidence from recent work.
This is a suggested segment within a retrospective, not an additional Scrum requirement.
- Five minutes: confirm the Sprint Goal outcome and choose the sample.
- Ten minutes: reconstruct the three items using available evidence.
- Five minutes: select one recurring or significant cause the team can influence.
- Five minutes: agree an experiment, owner and review point.
Give people time to explain disagreement. A board timestamp may show when a card changed columns without showing why it was waiting.
Copy this carry-over investigation note
Purpose: Record the investigation and the experiment the team will review.
- Item and intended outcome:
- What remained unfinished:
- What changed or caused waiting:
- Evidence and gaps in the account:
- Effect on the Sprint Goal:
- Cause to investigate further:
- Experiment and person coordinating it:
- Review date and evidence to inspect:
Choose a test you can learn from
Purpose: Choose a small change with an observable result.
Keep the experiment narrow. “Improve planning” is difficult to inspect. “Confirm one worked calculation example before selecting the next reporting item” gives the team something observable.
At the review point, ask what happened and whether the change helped. A single sprint cannot establish a reliable trend. Repeat or adjust the experiment if the evidence warrants it, without turning a tentative improvement into a permanent rule too quickly.
If the cause sits outside the team’s control, name the decision or support needed and take it to someone with authority. A retrospective cannot resolve an organisational constraint simply by assigning the team another action.
Your next step
Bring three unfinished items to your next retrospective. Reconstruct what happened before discussing estimates. Leave with one experiment and a date to examine its result.
See the official Scrum Guide for the Definition of Done and treatment of unfinished work. The sample size, investigation note and timing above are optional techniques.
You May Also Like
Exploring the Spotify Model: A Guide to Agile Development at Scale
The security update cannot wait: how to prioritise urgent fixes
