Why Sprint Estimates Are Wrong and How to Fix Them
May 2, 2026·11 min read·by Ihab Hamdy
Sprint estimation is the ritual that every engineering team performs and almost
none perfects. The failure mode is predictable: the team estimates based on
planned work and ignores the unplanned overhead that will consume 20–40% of
the sprint. CI failures, production incidents, review bottlenecks, stale PRs —
none of these appear on the sprint board, but all of them eat into the sprint's
effective capacity. Until you measure them, you can't account for them.
The real reason sprint estimates are wrong
The standard diagnosis for estimation failure is story points: teams use them
inconsistently, velocity isn't stable, point inflation happens over time.
Story points are genuinely problematic. But they're not the primary cause of
sprint misses in most teams.
The primary cause is unplanned interrupt rate — the percentage
of sprint capacity consumed by work that wasn't on the board when planning happened.
For a typical 10-person engineering team, the interrupt breakdown per sprint looks like this:
CI failures requiring investigation: 2–4 hours per sprint per engineer (varies by pipeline health)
Production incidents: 4–8 hours per sprint for the team when they occur (1–2 incidents/sprint is typical for teams without strong CI gates)
PR review requests outside planned work: 3–6 hours per engineer per sprint
Dependency unblocking: 2–4 hours per sprint per engineer (waiting on or unblocking other teams)
Context switches from stale PR escalations: 1–2 hours per sprint
Sum these up: the average engineering team is losing 30–40% of their
sprint capacity to unplanned interrupts that don't appear anywhere in
their sprint planning estimates. They plan 100% of capacity for planned work,
then wonder why 60–70% of it gets done.
The solution is not to estimate better. It's to measure your interrupt rate
and plan capacity accordingly — then work to reduce the interrupt rate over time.
Recommended for you
Measure your real interrupt rate
Estimates break when unplanned work is invisible. Deviera surfaces the interruptions eating your sprint from your actual GitHub and CI activity — automatically.
You can't plan around interrupt rate you haven't measured. The first step is
establishing a baseline over 3–4 sprints. You don't need perfect precision —
you need a directionally accurate picture of where the unplanned time is going.
The four interrupt categories to track:
CI failure response time. How many CI failures occurred in
the sprint, and what was the total engineering time spent investigating them?
A failed CI run that gets fixed in 15 minutes is different from one that requires
2 hours of root cause analysis. Track count and time separately.
Production incident time. Total hours the team spent on
production incidents — from first alert to resolution. Include both the
primary responder time and the secondary time of people who were pulled in
to assist.
Review queue overflow. How many PRs per engineer per sprint
arrived as review requests outside their planned sprint work? This is the
"teammates asking for reviews" interrupt that's easy to overlook because
it feels like normal work — but it's not in the sprint estimate.
Coordination overhead. Time spent unblocking dependencies,
attending cross-team syncs that weren't in the sprint plan, or investigating
shared infrastructure issues. This is the hardest to measure but often the
largest category in multi-squad organizations.
After 3 sprints of tracking, calculate your interrupt rate: total interrupt
hours ÷ total available sprint hours. A rate of 25–35% is typical for teams
without strong CI automation. A rate above 40% indicates a structural problem —
the team is spending nearly half their time on work that doesn't appear in planning.
The four metrics that make sprint capacity predictable
Once you know your interrupt rate, you can plan around it. But the deeper goal
is to reduce it — which requires tracking the metrics that predict interrupt
rate changes before the sprint starts.
1. CI pass rate (rolling 30-day average).
Your CI pass rate is your single best predictor of CI-related interrupt time
next sprint. A team at 95% CI pass rate has predictable, low interrupt time
from CI. A team at 82% CI pass rate will spend significantly more sprint
capacity on CI failure investigation than their estimates account for.
Track the trend, not just the current number.
2. Open production incidents at sprint start.
Any production incident that's open when sprint planning happens will consume
unplanned capacity during the sprint. "We'll finish the sprint work and get
to the incident" is how incidents stay open for three sprints. Count open
incidents at planning time and factor in at least 4 hours per open incident
as reserved sprint capacity.
3. PR review lag (90th percentile).
If 90% of PRs get reviewed within 4 hours, review queue interrupts are a minor
overhead. If 90th percentile review lag is 2+ days, engineers are being pulled
out of planned work to review PRs that sat too long. High review lag compresses
into interrupt bursts — people suddenly needing 4 reviews in one day rather than
steady-state one per day.
4. Stale PR count at sprint start.
Every stale PR (>3 days without review activity) at sprint start represents
pending context reload for the author and pending review time for a senior
engineer. A sprint starting with 8 stale PRs will resolve most of them in
the first 2 days — burning capacity that wasn't planned for.
Building a feedback loop between sprint outcomes and future estimates
The most important practice in improving estimation accuracy is the sprint
capacity retrospective — a dedicated 15-minute review at sprint close that
answers one question: where did the time actually go?
Structure it around four buckets:
Planned work completed: story points or tickets finished
Planned work not completed: what was estimated but not delivered, and why
Unplanned work completed: CI failures, incidents, reviews, coordination — estimate hours
Process improvement impact: did last sprint's process changes reduce interrupt time?
After 3–4 sprints of this retrospective, two things become clear: your interrupt
rate baseline (with enough confidence to factor it into planning), and whether
the process changes you're making are actually reducing it.
Teams that do this consistently for 2 quarters typically improve sprint estimate
accuracy by 35–45%. Not because they got better at estimating features — but
because they stopped underestimating the overhead that was always there.
The sprint planning calibration checklist
Before sprint planning
Pull CI pass rate for the last 2 weeks — factor in CI interrupt rate accordingly
Count open production incidents — reserve capacity for each
Count stale PRs — estimate review time to clear the backlog in sprint week 1
Check previous sprint interrupt rate — use as the baseline overhead deduction
During sprint planning
Explicitly name planned capacity as: total available hours × (1 - interrupt rate)
Reserve a "buffer pool" of hours (10–15%) for unplanned interrupts — make it visible, not hidden
If CI pass rate is below 90%, add explicit CI remediation work to the sprint board (not just buffer)
At sprint close
Record actual interrupt hours by category (CI, incidents, reviews, coordination)
Compare to the buffer pool — did actual interrupts exceed the reserve?
Update the interrupt rate baseline for next sprint planning
Identify the highest-interrupt category and add one process improvement action to the next sprint
The teams that plan most accurately aren't clairvoyant — they're instrumented.
They know their interrupt rate because they measured it. They know their CI pass
rate because they track it weekly. They know their stale PR count because it's
on their dashboard, not hiding in a GitHub list they haven't checked this week.
Estimation accuracy is a data quality problem. Fix the data, and the estimates follow.
Before your next sprint planning, get a baseline on the two metrics that matter most:
CI Health Score Calculator — score your pipeline failure rate and recovery time, the primary source of unplanned sprint interrupts
PR Cycle Time Calculator — measure your review lag and merge gap, which drive the review queue overflow that inflates your interrupt rate
Because they estimate the work and then assume the whole week is available for it. Real capacity is typically sixty to seventy percent of nominal — the rest goes to CI failures, incidents, review and re-review, and coordination. Teams then treat the shortfall as an estimation failure and try to estimate more carefully, which cannot help, because the error is in the capacity assumption rather than in the sizing of the work.
How do you measure a team's real interrupt rate?
Count the hours that went to unplanned work for two or three sprints, without judging any of it. The categories that dominate are CI triage, incident response, unplanned review rounds, and cross-team requests. Once you have a number, plan against actual capacity rather than nominal. Most teams discover the rate is stable enough to plan around, which is what makes it useful — an unpredictable interrupt rate is a different and more serious problem.
Should you pad sprint estimates to account for interruptions?
Reduce the capacity rather than inflating the estimates. Padding individual items hides where the time goes and quietly teaches everyone that estimates are fiction, so they stop being useful for sequencing. Explicitly planning at sixty-five percent capacity keeps the estimates honest and makes the interrupt load visible as its own line — which is also what lets you argue for reducing it.
Do story points make estimates more accurate?
They make relative sizing easier and absolute prediction no better. Points are useful for comparing two pieces of work and useless for answering when something will ship, because the conversion to time depends on the capacity assumption that was wrong in the first place. If the goal is predictability, measuring cycle time on completed work forecasts better than points, and requires no estimation meeting at all.
