A 2026 survey asked 419 engineers, product managers, and project managers one simple question: How confident
do you feel about your sprint estimates? 63% said very confident. Another 24% said moderately
confident.
Then it asked something else: how often do tasks end up significantly larger or smaller than you estimated? 44% of
Teams said it happens on roughly half of their work.
Read those two numbers together, and you get the actual problem. Not that teams are bad at estimating, but
Teams feel confident about estimates that are consistently wrong. And when confidence is high, nobody goes
looking for the real cause. The sprint misses; the retrospective produces some version of "we need to estimate
better," and the next sprint starts with the same process and the same result.
Most articles about sprint estimation focus on the technique – story points versus hours, planning poker versus
t-shirt sizing. This one is about something more fundamental: why estimation keeps failing regardless of which
technique teams use, and what the teams that have fixed it actually changed.
The Confidence Trap
Here is the part that makes sprint estimation hard to fix: the problem is not that teams are uncertain. It is that they
are not uncertain enough.
Research puts it clearly — work takes about 30% longer than estimated on average. Even when someone says
They are 90% sure a time range will cover the actual effort; that range only holds 60 to 70% of the time. Which
means the feeling of confidence and the reality of accuracy are barely related. You can feel very sure about an
30%
longer — how much work takes on average vs the estimate,
and still be wrong most of the time.
The reason this matters so much is what happens when confidence is high. When a developer feels certain about
a 5-point estimate, they do not flag the things they do not know yet. They do not ask about the dependency that
might not be ready. They do not push back on the sprint loading up with more than the team has realistically
delivered before. The confidence closes the conversation before the useful questions get asked.
Estimation becomes a problem when it turns into a ceremony — a series of numbers assigned to tickets so the
planning session can end and the sprint can start. At that point, the goal of estimation has shifted from
understanding the work to completing the ritual. And rituals produce confident-sounding numbers, not accurate
ones. The sprint starts with a full board and a team that feels good about their plan. Day eight arrives with three
tickets in progress, and nobody is sure how it happened again.
Why Sprint Estimates Break Down — The 6 Real Reasons
Understanding exactly where estimation fails helps teams fix the right thing instead of the same wrong things they
fix every retrospective.
Reason 1: The ticket was estimated before it was understood
Someone sees a work item called "Update API". They give it 5 points based on the title alone. The team moves on.
Three days into the sprint, the developer opens the ticket and discovers the API update requires three separate
services to change, a migration script, and coordination with another team that owns a dependency. The 5-point
A ticket is a 21-point problem.
This happens constantly, and it happens because estimation often precedes understanding. The problems only
become visible when someone starts working, which is too late to adjust the sprint without disruption. Without an
adequate understanding of a ticket before it enters the sprint, teams are forced to estimate based on assumptions
that often prove incorrect.
Reason 2: The estimate was a solo guess, not a shared risk check
Most estimation sessions end with the most senior engineer's number becoming the consensus after two or three
rounds. What is missing is the conversation that should happen when estimates diverge significantly. When one
engineer says 3 and another says 13, that gap is not a problem to resolve quickly — it is information. It means two
people have fundamentally different mental models of what this ticket involves. When that conversation gets
compressed to reach consensus faster, the uncertainty stays hidden and shows up later in the sprint.
Reason 3: Capacity was planned optimistically, not honestly
Ten working days in a two-week sprint sounds right. In practice, a developer doing focused technical work gets
maybe six or seven of those days. Everyone knows this — and most sprint planning sessions quietly ignore it. The
problem gets worse after a sprint that went unusually well. The following sprint gets planned against that best-case
capacity, and the over-commitment is baked in before the first standup. The only fix is honesty: what did this team
actually complete in the last four sprints, and does today's commitment match that number?
Reason 4: Dependencies were assumed rather than confirmed
A ticket depends on an API from another team. The developer assumes it will be ready by day four without
confirming. The other team's sprint ends on day seven and the API is not ready. By the time this surfaces in
standup, several days are lost and the ticket carries over. The fix is simple: before the sprint locks, every ticket with
an external dependency needs a confirmed owner and confirmed timeline. If that confirmation does not exist, the
ticket is not ready to commit to.
Reason 5: The sprint had no clear goal — just a list of tickets
Ask most teams what their sprint goal is and they will read you the list of tickets. That is not a sprint goal — that is a
to-do list wearing a sprint goal costume. When five developers each optimise for their own tickets, nobody owns
the connective work. Everyone finishes their assignment and the sprint review reveals that the pieces were all built
in parallel without anyone checking they fit together. A real sprint goal is one sentence with a testable outcome.
That sentence answers every mid-sprint trade-off question without calling a meeting.
Reason 6: Estimates were treated as commitments rather than forecasts
When an estimate becomes the number a developer is held to, the incentives shift. Developers pad to protect
themselves. Product managers' challenge to protect the roadmap. The number that comes out represents neither
person's honest assessment — it is a political compromise between self-protection and schedule pressure. The
teams that estimate most accurately have separated estimation from commitment: the estimate is a shared best
Guessing is for making planning decisions, and commitment is made to the sprint goal, not the point count.
Table 1 — The 6 Reasons Sprint Estimates Fail
What High-Performing Teams Actually Do.
The teams that deliver on sprint commitments consistently are not necessarily better at estimation. Some of the
highest-performing engineering teams have almost entirely deprioritised precision in their estimates — and their
Delivery has improved. The change is not in how accurately they estimate individual tickets. It is in what they use
estimation for and what they do instead of relying on it.
They treat estimation as a complex conversation, not a number
The point of estimation is not to produce a number. It is to surface complexity, dependencies, and risks the team faces.
does not yet know about. When two engineers give very different estimates for the same ticket, high-performing
Teams do not move on until those two engineers have explained their mental models to each other. That
conversation — "I estimated 13 because I think we need to change three services" versus "I estimated 3 because I
assumed it was just a config change" — is where the real planning happens.
They use historical throughput, not ideal capacity
Instead of asking how much we can theoretically do in ten days, high-performing teams ask how much we have
actually delivered in the last four sprints. That number — actual throughput, not planned capacity — becomes the
ceiling for the next sprint's commitment. Teams that track this honestly and use it as the planning ceiling are 23%
more accurate in their estimation, according to research from the Scrum Alliance.
They protect 15–20% of the sprint capacity for unplanned work
Unplanned work is not an exception — it is a permanent feature of engineering teams. Teams that plan at 100% of
Their capacity has no room to absorb it without impacting the sprint. Teams that protect 15 to 20% of their capacity
as a buffer absorb unplanned work and still deliver the committed scope. That buffer is used in almost every sprint —
usually on something that genuinely mattered.
They start every sprint with a one-sentence goal, before touching the backlog
Before any ticket is added to the sprint, the team writes one sentence describing what success looks like. Every
ticket that enters the sprint is then evaluated against that sentence. This prevents the most common form of sprint
failure and provides the team with a decision framework for mid-sprint trade-offs. When something unexpected
happens, the sprint goal answers the question without a meeting.
They run a pre-planning dependency check before the sprint locks
Thirty minutes before sprint planning ends, high-performing teams walk through every ticket with an external
Dependency and confirmation: Is it confirmed? Does the person on the other side know they are being relied on, and by
When? If the answer is no, the ticket does not enter the sprint. This single habit eliminates one of the most
consistent causes of sprint failure. The conversation takes thirty minutes before the sprint. Discovering the gap
Mid-sprint costs days.
Table 2 — What High-Performing Teams Do Differently
What to Track Instead of Story Points
Story points were designed as a relative complexity measure — a tool for conversations about effort and
uncertainty. They were never designed to be a performance metric, a velocity KPI, or a management reporting
number.
When story points become a performance metric, teams inflate them to look productive. When they become a
commitment number, teams pad them to protect themselves. In both cases, the number stops reflecting anything
real.
The metric that actually predicts sprint delivery is throughput — the number of tickets completed per sprint.
measured honestly over time. Throughput is harder to game. A ticket is either done or it is not. Tracking throughput
Over twelve to sixteen sprints give a team a genuinely predictive baseline for planning. Teams that use throughput
Rather than story points as their planning metric, they are measurably more accurate from sprint to sprint.
Table 3 — Story Points vs Throughput as Planning Metrics
The Thing Nobody Says in Retrospectives
Here is what most sprint retrospectives do not say out loud: the estimate was wrong because nobody wanted to be
The person who said it might take longer.
Estimation accuracy is partly a technical problem — teams need better processes, better data, and better planning
habits. But it is also a cultural problem. In teams where admitting uncertainty is treated as a lack of confidence,
Developers give optimistic estimates to avoid appearing slow or inexperienced. In teams where
challenging a stakeholder's timeline is treated as obstructionism, estimates get compressed to fit the roadmap
rather than to reflect the work.
The teams that estimate most accurately have established a norm of saying, "I don't know enough to estimate this yet."
is treated as good engineering judgement. Where "that dependency is not confirmed" stops the sprint plan before
the sprint starts. That norm does not come from a better estimation technique. It comes from a team that has
decided honesty about uncertainty is more valuable than the temporary comfort of confident-sounding numbers.
How Spryn Approaches This Problem
Most sprint tools treat estimation as a planning input — you fill in your story points, they record them, and if the
Sprint misses; you see it in the burndown after the fact.
Spryn (spryn.io) is built around the principle that sprint health should be visible before problems become
unrecoverable — not as a chart you check, but as a signal you act on from the same screen where you manage
the sprint.
When a sprint in Spryn starts drifting from its commitment — a ticket has not moved in two days, scope has quietly
grown, a key task is showing no progress — that signal is visible on the sprint board immediately, with the action to
Address it right there. No report to generate, no dashboard to configure. The Scrum Master sees what needs a
decision. The decision gets made while there is still time to do something about it.
For teams that have been explaining sprint failures instead of preventing them, that is the shift that changes the
pattern.
Questions Teams Ask About Sprint Estimation
Is the problem story points specifically, or estimation in general?
Story points are not the problem — how teams use them is. They work well as a tool for surfacing complexity
during planning conversations. They stop working when they become a performance KPI or a commitment teams
are held to. The teams that get the most out of story points use them purely as an internal planning language and
track throughput separately as their predictive metric.
Should we stop estimating altogether?
Some teams — particularly very small, high-trust engineering teams — have moved to no-estimate approaches
with success. But for most teams, estimation still forces a valuable conversation about complexity and
dependencies before work begins. The goal is not to stop estimating. It is to stop treating estimates as contracts
and stop letting confidence substitute for accuracy.
How many sprints of data do we need before throughput becomes reliable?
Most practitioners recommend twelve to sixteen sprints of clean throughput data before using it as a primary
planning input. The first few sprints of any new team will have high variance — that is normal. The pattern
stabilises over time, and once it does, historical throughput is significantly more predictive than any individual
sprint's point estimates.
Our stakeholders need commitment dates. How do we give them that without accurate estimates?
You give them ranges, not dates, and you explain the range using data. "Based on our throughput over the last
'Eight sprints, a feature of this scope has historically taken three to four sprints to complete' is more honest and
more useful than a single date derived from estimates that had a 40% chance of being wrong. Stakeholders who
understand how software development works respond better to honest ranges than to confident dates that slip
repeatedly.