What points are actually for
Estimating in hours invites a precision nobody has. A developer asked "how long will this take?" produces a number that silently bundles the coding, an unknown amount of review latency, whatever the test environment does that week, and their own optimism, and the figure then gets treated as a commitment because it is denominated in a unit that sounds measurable. Relative sizing removes that trap by asking a question people are genuinely good at: is this bigger or smaller than the thing we already did, and roughly by how much? Humans are poor absolute estimators and decent comparators, and a coarse non-linear scale is honest about confidence degrading as size grows, which is why a 13 exists but a 12 does not.
The more important point, and the one weak answers miss, is that the number is a by-product. The value of the estimation conversation is the disagreement it exposes. When one person says 2 and another says 8, that gap is almost never about typing speed. It is a hidden dependency, an unstated assumption about whether the legacy adapter is being replaced, a piece of the domain one person understands and the other does not, or an acceptance criterion that means two different things to two people.
Planning poker is a cheap mechanism for finding that misalignment before the middle of the sprint does. A team that estimates silently and quickly is collecting numbers while discarding the thing that made them worth producing. Worth adding, if asked: the Scrum Guide does not mandate story points or velocity at all, so they are a widely adopted practice rather than part of the framework.
"Consistently wrong" is a symptom, not the diagnosis
If a team overruns every sprint, the instinct to send them on an estimation course is almost always wrong. Estimates that are randomly wrong in both directions are working as intended; that is what a probabilistic size is. Estimates wrong in the same direction every single sprint mean something systematic is being left out, and the job is to find out what.
The usual suspects, roughly in order of how often they turn out to be the cause:
- Acceptance criteria that were not clear at estimation time. The team sized the story they imagined and built the story the Product Owner meant. This shows up as scope discovered mid-sprint, not as slow coding.
- Stories too large to reason about. An 8 or a 13 is usually a story nobody could decompose in their head, so the number is a guess wearing a Fibonacci costume. Large items also fail atomically: an 8 that does not finish scores zero, making sprint outcomes lumpy.
- Work that exists but is not counted. Review latency, testing, environment setup, deployment, the fix after UAT feedback. If the definition of done includes these but the estimating conversation does not, the gap is structural.
- Interruption load. Production support, escalations, another team needing an hour daily. Teams routinely plan as though capacity were 100%.
- Points quietly converted into a target. Once velocity is something the team is judged on, the number stops describing reality: estimates inflate, nearly-done is reported as done, and the metric loses its forecasting value. Goodhart's law, arriving on schedule.
A worked example
A six-person team plans around 34 points a sprint. Three sprints in a row they deliver 22, 24 and 20, then commit to 34 again. Rather than debating the next sprint's number, pull the last twenty completed stories and look at what actually happened to them.
| What was measured | What the last twenty stories showed |
|---|
| Cycle time for stories sized 3 | 2 days to 11 days |
| Time in "ready for review" | 9 of 20 stories waited 3 days or more |
| Acceptance criteria changed after sprint start | 6 of 20 |
| Unplanned support work | roughly 1.5 days per person per sprint |
That table reframes the problem. The 3-point stories were not badly sized; their build time was consistent and the variance came almost entirely from queue time waiting for a reviewer. A quarter of the team's real capacity was going to support work that never appeared in the plan. And a third of the stories grew after they were estimated, which no estimation technique survives.
None of the fixes are estimation fixes. Cap story size so nothing above a 3 enters a sprint, which improves the estimates and makes partial failure cheaper. Make review a first-class part of the work with a WIP limit that forces reviewing over starting. Put the measured interruption load into planning explicitly, so the plan is 24 points and honest instead of 34 points and fictional. And refuse to start a story whose acceptance criteria are still moving. The velocity that emerges is lower on paper and far more predictable, and predictability was the only thing anyone actually wanted.
Velocity is a local, self-referential unit. It is meaningful only to the team that produced it, only while that team's composition and estimating habits are stable, and only as an input to their own next plan. Comparing two teams' velocities is meaningless because the unit is not shared. Setting a velocity target is actively harmful because the team controls the numerator, so the target is trivially met by inflating estimates while delivering the same amount of software. Being willing to say that to a director is one of the strongest signals available here.
Forecasting more honestly
Throughput, the count of items completed per unit time, and cycle time, the elapsed time from start to done, are better forecasting inputs precisely because nobody estimates them. They are observed. If the last ten sprints produced 7, 9, 6, 8, 11, 7, 5, 9, 8 and 6 completed stories and roughly 45 stories remain, the arithmetic gives a range of about five to nine sprints with seven most likely, and resampling that history yields a distribution rather than a single number. The same data gives a service-level expectation per item: if the 85th percentile cycle time is nine days, you can tell a stakeholder a started item is usually done inside nine days without estimating it at all.
This works on one condition, which is that items are roughly similar in size and counted consistently. That is another reason to split aggressively.
When leadership demands a date
Refusing to give a date is not a professional answer, and neither is inventing one. Give a range with an explicit confidence, name the assumptions it rests on, and hand back a lever. "Based on the last ten sprints, we are 85% confident this scope lands between mid-October and mid-November, assuming the two payments-team dependencies land in September and support load stays where it is.
If you need October with high confidence, here is the scope we would cut." That answer is auditable, it makes the date a shared decision rather than a promise extracted from the team, and it gives the person asking something they can work with. Then re-forecast every sprint and communicate movement early, because a date that quietly slips at the end is far worse than one that visibly moved in week three.
The trap
The trap is answering the second half as though it were an estimation-accuracy problem. Candidates offer three-point estimates, reference-story recalibration or more disciplined planning poker, all of which is fine and none of which addresses a team that is wrong in the same direction every sprint. Chronic one-sided error is evidence about the system, not about the estimators. The strong answer goes looking for the missing work, the oversized items, the queue time and the interruption load, and names the possibility that pressure on velocity has corrupted the numbers. A weaker answer treats the estimate as the defective artefact when it is only the messenger.
Estimates that are randomly wrong are working correctly; estimates that are wrong in the same direction every sprint are telling you something about the system, and the fix is almost never a better estimate.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).