Why Sprints Fail: The Seven Patterns Behind Missed Commitments
When a sprint misses, the retro often lands on "we underestimated". Sometimes that is true. More often the data shows one of a handful of structural patterns, each with a different fix.
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.
Sprints miss for different reasons — overcommitment, scope added mid-sprint, or work waiting downstream — and each looks the same in a completion rate.
How this is calculated: Where the unfinished work sits in the methodology
What "sprint failure" really means
A sprint "fails" when the original commitment is not completed. That is a statement about the plan, not about the team's effort. A team can work flat out and still miss a commitment that was never achievable, or that stopped being the operating plan on day two.
Across many teams, missed sprints fall into a small number of recurring patterns. Each leaves a distinct signature in the data, which is what makes them diagnosable rather than a matter of opinion. The question worth answering is which of these patterns explains the gap:
| Pattern | Signature in the data |
|---|---|
| 1. Over-commitment | Many committed issues never started; commitment above historical throughput |
| 2. Scope creep | High net scope growth; added work completed while original work carries over |
| 3. Review queue | Many issues in code review at close; review time above baseline |
| 4. QA crunch | Issues reaching QA in the final days; QA queue at close |
| 5. Release backlog | Finished work in "ready for release" at close |
| 6. Dependencies | Blocked time during the sprint |
| 7. Unclear requirements | Clarification waits; thin descriptions on unfinished issues |
Why distinguishing them matters
Each pattern has a different owner and a different fix. Over-commitment is a planning conversation; a review queue is a team-norm conversation; a release backlog is a release-engineering conversation; unclear requirements are a product conversation. Treating them all as "estimate better" fixes none of them.
How to identify the pattern
Sprint 20
60 → 56gap 4
Sprint 21
65 → 57gap 8
Sprint 22
72 → 58gap 14
Sprint 23
78 → 59gap 19
- Committed ↑ +18
- Completed → +3
Expected carryover ≈ commitment − demonstrated throughput = 78 − 58 (median of 56, 57, 58, 59) ≈ 20 issues
Reconstruct the sprint as a sequence of countable facts, then look at which factors are present in the unfinished work:
- How many issues were committed at start, carried in, added, removed?
- Where was each unfinished issue at close?
- Which unfinished issues were blocked, waited on clarification, had extended review, or reached QA late?
- Rank factors by how many unfinished issues show them.
Factors overlap — one issue can be added mid-sprint and stuck in QA — so present them as "contributing factors", not as percentages that add up to 100.
What data each pattern needs
Over-commitment, carry-in and stage-at-close for the most recent sprint can be seen in a standard Jira CSV export. Scope creep needs sprint start dates (and ideally Sprint field history). Blocked time, clarification waits, extended review and late QA arrival can only be observed with status-transition history. If you do not have that history, say which patterns you could not check rather than assuming they were absent.
How to interpret the ranking
- Sprint starts64 issues committed
- Day 3+5 added
- Day 7+8 added
- Day 10+5 added
- Sprint ends82 issues in scope
- Original commitment
- 64
- Final scope
- 82
- Scope growth
- +28%
58 completed looks like 71% of final scope. Against the plan the team made, and the 18 issues that arrived after it, the story is different.
Comparing completed work only with final scope hides what happened during the sprint — compare with the original commitment too.
- If the top factor is a stage at close (review, QA, release), that stage is likely the constraint.
- If the top factor is added after start or never started, the problem is the plan, not the flow.
- If carried in dominates, the team is in a carryover spiral — plan less new work until it drains.
- If factors are spread thin, look at the trend: a single bad sprint may just be an event.
Every conclusion should link back to the issues behind it. If you cannot point to the issues, you have an opinion, not a finding.
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.
Common mistakes
- Defaulting to "underestimation". Check the patterns first.
- Inferring causes the data cannot support. Without status history, you cannot know who waited in review last month.
- Fixing everything at once. Pick the top factor, change one thing, re-measure.
- Turning it into blame. Patterns are properties of the system and its policies.
- Reading one sprint in isolation. A single QA crunch during a holiday week is an event; the same crunch three sprints running is a constraint.
What to do
| Pattern | First change to try |
|---|---|
| Over-commitment | Commit within the historical median; see capacity planning |
| Scope creep | Swap rule for additions; buffer sized to typical growth; see scope creep |
| Review queue | Review before starting new work; smaller PRs |
| QA crunch | Finish development earlier; developers help verify |
| Release backlog | Increase release frequency |
| Dependencies | Confirm external dependencies before commitment |
| Unclear requirements | Acceptance criteria before commitment |
Change one thing at a time and re-measure after a sprint or two. If the top factor shrinks and completion improves, keep the change; if the constraint simply moves downstream (review improves, QA becomes the queue), that is progress — address the new constraint next.
Example
Sprint 15 started with 30 committed issues, 17 of them carried in. It completed 60% of the commitment. Among 13 unfinished issues: 9 were sitting in QA at close, 6 had spent more than four days in QA, and 2 reached QA in the last two days. QA capacity had been halved that sprint. The dominant pattern is a QA crunch — not over-estimation and not effort.
How this tool helps
See it on your own data in the Why didn’t we finish? report.
Sprint Forensics — "Why didn't we finish?" — builds exactly this reconstruction from your export, ranks contributing factors, links every fact to its issues and labels each one Observed, Inferred or Unavailable.
Frequently asked questions
- What is the most common reason sprints fail?
- Over-commitment and mid-sprint scope change are the most common, followed by queues in review, QA or release. The data usually shows which one applies.
- Is missing a sprint commitment always bad?
- Occasional misses are normal, especially for ambitious teams. Persistent misses mean the plan does not reflect reality and should be recalibrated.
Related guides
Reduce carryover
A practical, evidence-first playbook for reducing sprint carryover: diagnose by stage, right-size commitments, limit WIP, and fix the constraint instead of pushing harder.
Engineering bottlenecks
How to find delivery bottlenecks in an engineering workflow using queue size and time-in-stage, why arbitrary red/amber/green thresholds mislead, and what to do once you find the constraint.
Sprint scope creep
How to measure sprint scope creep from Jira — original commitment, added, removed, net growth — why CSV exports undercount it, and how engineering managers can control it.
Capacity planning
Plan sprint commitments against historical throughput ranges instead of optimistic capacity math. Include existing WIP and typical scope growth, and communicate risk honestly.