Estimation Deep Dive
Story points estimate the effort, complexity, and uncertainty of a piece of work relative to other work. This guide covers how to assign points, how to keep a scale consistent, and how to improve estimation accuracy sprint after sprint.
Points only mean something relative to each other, so pick a well-understood, already-completed story as your anchor. If that story is a three, the team estimates everything else by comparison to it.
Keeping one or two reference stories per size visible during estimation stops the scale from drifting. Without anchors, a five in January quietly becomes a three by June and velocity loses its meaning.
A point value should reflect more than raw hours. A short task with a scary unknown can deserve more points than a long but routine one, because uncertainty is part of the cost.
When the team votes and the spread is wide, the gap is usually about risk, not effort. Surfacing that disagreement is the point, and it often turns into a clarified requirement or a smaller, safer story.
Estimation is a skill the team builds, not a formula. Reviewing a few finished stories each retrospective, and asking whether their points matched reality, calibrates future estimates far better than trying to be perfect up front.
Resist the urge to re-estimate completed work to make velocity look better. The value of points comes from consistency, and adjusting history to flatter a chart destroys the signal you are trying to build.
Most teams use a Fibonacci-style scale because its widening gaps discourage false precision. The exact numbers matter less than using them consistently.
The team owns it. Whoever picks up the story should be able to complete it in roughly the estimated effort, so estimates must not assume a single specialist.
Underestimation usually means stories are too large or unknowns are ignored. Split big items and factor risk into the point value rather than inflating the whole scale.