Where Sprint Estimates Go Wrong — and What Disciplined Teams Do Instead
Estimation is where many Scrum teams quietly lose credibility. The Sprint demo goes fine, the burndown looks tidy, and yet stakeholders still feel the team "never delivers what it promised." Usually the work was solid; the estimates were not. After two years of remote and hybrid Scrum — teams scattered across home offices, suppliers still slipping deliveries — the gap between a confident number and a real outcome has only become more expensive to ignore.
The Scrum Guide is deliberately quiet on technique here. It says the Developers are accountable for sizing Product Backlog items and that the Product Owner can influence trade-offs, but it does not prescribe story points, hours, or any particular method. That freedom is the trap: without shared discipline, estimation drifts into wishful thinking.
What bad estimation looks like
You can spot a struggling team by how it talks about numbers. The symptoms are consistent across industries and they compound quietly.
One senior person calls out a number and everyone nods — the loudest voice becomes the estimate.
Story points are quietly converted to hours, so a "5" really means "about two days" and all the relative-sizing value is lost.
Estimates are treated as commitments, then used as a stick when reality differs.
Unknowns are priced as if they were known — a vague integration gets a small number because nobody wants to look slow.
The team estimates the same way for a familiar feature and a first-of-its-kind spike, ignoring how much uncertainty differs.
The remote-work era made the worst of these habits easier to hide. On a video call it is simpler to defer to whoever speaks first, and harder to read the quiet hesitation that signals a real risk.
What good estimation looks like
Good estimation is not about being right to the decimal — it is about being honestly calibrated and improving over time. Disciplined teams build a few habits.
Estimate relatively, not absolutely. Compare a new item to a reference item the team already finished. "Is this bigger or smaller than that login story we did?" is a more reliable question than "how many hours is this?"
Surface disagreement before averaging it away. When two people give very different sizes, that gap is information. Planning Poker works because the discussion it triggers — not the card — is the point.
Price the uncertainty, not just the work. If an item depends on an unknown API or a supplier whose lead times are unstable, the estimate should reflect that risk or be split into a spike first.
Re-estimate when you learn something. An estimate made before discovery is a guess; once the team understands the work, an honest update is not a failure.
Track forecast versus actual without blame. Review where estimates drifted, look for the pattern, and adjust. The goal is a more trustworthy forecast next Sprint, not a scapegoat this one.
Notice what is missing: none of this requires perfect numbers. A team that consistently delivers what it forecast — even a modest amount — earns far more trust than one that promises big and misses. For public-sector and capital-project clients, where a Sprint forecast can feed a board update or a funding milestone, that reliability is the whole game.
Making the change stick
Start small. Pick one reference story everyone agrees on and size against it for a few Sprints. Keep estimates in points and resist the urge to translate them into a calendar. Let velocity emerge from history rather than negotiating it upward. Within three or four Sprints, a hybrid team usually has a forecast it can actually stand behind — and conversations with stakeholders shift from defending numbers to discussing real trade-offs.
If your delivery teams are estimating on hope rather than evidence, XNM's program & project delivery advisory can help you build forecasts your stakeholders trust.