How to Measure and Improve Sprint Predictability
A predictable team is one whose plans can be relied on: when it commits to something, leadership can build on it. That is not the same as a high completion rate — and measuring it as a single ratio often makes teams less predictable, not more.
Part of Engineering Delivery Intelligence: better planning and fewer surprises
This guide answers
- Why isn’t completed ÷ planned enough?
- Which signals make up predictability?
- How do you tell a planning problem from a flow problem?
- What actually improves predictability?
Why predictability is not simply completed ÷ planned
Sprint A
45 of 60 completed
- No scope change
- 15 unfinished, 12 still in development
- Planning problem: committed above throughput
Sprint B
60 of 80 completed
- +20 added mid-sprint
- Original plan: 42 of 60 (70%)
- 20 unfinished, 14 waiting in QA
- Flow problem: testing is the constraint
Identical ratios, opposite problems. One needs a smaller plan; the other needs a testing fix.
Both sprints report 75%. Sprint A committed to more than the team can deliver; the fix is a smaller, better-informed plan. Sprint B absorbed a large mid-sprint change and then ran out of testing capacity; the fix is intake discipline and QA capacity. A single ratio treats them as the same sprint.
The ratio also creates a perverse incentive. If predictability is judged by completed ÷ planned, the easiest improvement is to plan less. The number goes up; nothing about delivery changes.
The signals that make up predictability
- Original commitment
- What was promised at the start
- Final scope
- What the team ended up responsible for
- Scope growth
- How stable the plan was
- Completion
- Of the original plan
- Of final scope
- Carryover
- How much rolled into the next sprint
- Chronic carryover
- Work that keeps rolling — a decision nobody made
- Stage at sprint close
- Whether unfinished work was stuck early or late in delivery
- Historical pattern
- Whether this sprint is normal for this team
Each signal answers a different part of “can we rely on this plan?”
None of these is predictability on its own. Together they describe how reliable the plan was, why it moved and whether that is getting better or worse.
Reading the pattern over several sprints
| Sprint | Committed | Added | Completed | Carried over | Carried 3+ sprints |
|---|---|---|---|---|---|
| Sprint 20 | 60 | +5 | 56 | 9 | 1 |
| Sprint 21 | 65 | +8 | 57 | 16 | 2 |
| Sprint 22 | 72 | +7 | 58 | 21 | 3 |
| Sprint 23 | 78 | +12 | 59 | 31 | 5 |
Sprint 20
60 → 56gap 4
Sprint 21
65 → 57gap 8
Sprint 22
72 → 58gap 14
Sprint 23
78 → 59gap 19
- Committed ↑ +18
- Completed → +3
Commitment rose from 60 to 78 while completed work held at 56–59. The plan became less predictable; the team did not.
Four sprints of history tell a clearer story than any single sprint. Completed work is steady. Commitment climbs by six to eight issues a sprint. Mid-sprint additions are modest. Carryover more than triples — and the number of issues carrying three or more sprints grows every time.
That pattern has one main cause: the plan keeps outgrowing the team’s demonstrated throughput, and unfinished work is re-planned on top of new commitments. The commitment vs completion guide walks through how to set the next commitment from this history.
Where unfinished work stops tells you what kind of problem it is
Team A · 31 unfinished
Most unfinished work is still in active development.
Team B · 48 unfinished
Most unfinished work is already downstream, waiting on review or testing.
The same amount of unfinished work can sit in very different places — and need very different fixes.
When carryover rises, check the stage each unfinished issue was in at sprint close. If most of it never left development, the plan was too big or the work too large. If most of it was in code review or QA, delivery flow is the constraint — and committing to less development work will not fix it.
This is why predictability belongs next to bottleneck analysis. A team can be perfectly realistic about its development capacity and still unpredictable, because testing or release cannot keep up.
How to improve sprint predictability
- Plan from demonstrated throughputUse the last four to six sprints, not estimates
- Subtract carried-in work firstUnfinished work is already a commitment
- Leave room for usual scope growthIf sprints grow 10–15%, plan for it
- Fix the stage where work stopsReview, QA or release — not always development
- Decide on chronic carryoverSplit, unblock or deprioritize explicitly
Start with the plan, then the flow, then the long tail.
- Plan from what the team has delivered, using a range (for example 56–59 issues), not a single estimate.
- Treat carried-in work as already committed. Plan new work only into the space that remains.
- Reserve room for the scope growth you usually see, and agree what gets traded out when it is exceeded. See how scope change affects outcomes.
- Look at where unfinished work stops, and fix that stage’s capacity or process.
- Make a decision on every issue carrying three or more sprints.
Predictability usually improves within two or three sprints once commitments are set from history — often without the team working any differently.
See this in VeloWise: Historical trends and capacity
Commitment, completion, scope growth and carryover across sprints, and a commitment simulator that tests a plan against demonstrated throughput.
Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.
Go deeper
Frequently asked questions
- What is a good sprint predictability percentage?
- Avoid a single target. Look for a stable pattern: original commitment mostly completed, scope growth within a known range, low chronic carryover. Stability over several sprints matters more than any one number.
- How many sprints of history do I need?
- Four to six closed sprints give a useful range for most teams. Fewer than three makes any pattern unreliable.
- Is predictability the same as velocity?
- No. Velocity is how much a team completed. Predictability is how closely what it completed matched what it planned — and why it differed.
Related guides
Sprint Commitment vs Completion: What the Numbers Really Tell You
When commitment rises and completed work stays flat, the plan — not the team — is drifting. How to read the gap and plan the next sprint.
How Scope Changes Affect Sprint Outcomes
Work added mid-sprint changes what a completion rate means. Track original commitment and final scope together to explain the sprint outcome.
Why Work Carries Over Between Sprints
Carryover is not automatically underperformance. Where work was at sprint close — and how long it has been carrying — shows what to change.
Sprint Health: Metrics That Help Explain Whether Delivery Is on Track
Sprint health is several signals, not one score: commitment, scope growth, progress, carryover, stage distribution, aging, blocked work and release.