The agile estimation unit explained — and why it works better than hours
THE DEFINITION
Story points are an abstract unit used in agile and scrum teams to estimate the relative effort, complexity, and uncertainty involved in completing a user story or task. Unlike time-based estimates, a story point doesn't map to a specific number of hours — a 5-point story is simply understood to be roughly twice the effort of a 3-point story.
The abstraction is intentional. It frees teams from the false precision of hour estimates and focuses discussion on complexity and risk instead.
WHY NOT JUST ESTIMATE IN HOURS?
Hour estimates sound precise but rarely are. They're optimistic by nature — developers consistently underestimate how long tasks take, especially when unknowns are involved. Hour estimates also vary by individual: a senior engineer might complete a task in 2 hours that takes a junior 6.
Story points sidestep both problems. Teams estimate relative to each other — "this is about twice as hard as the last one" — rather than committing to a clock time. Individual productivity differences average out over time through velocity.
THE FIBONACCI CONNECTION
Most teams use a Fibonacci-like sequence for story points: 1, 2, 3, 5, 8, 13, 21. The growing gaps between numbers are deliberate. Small stories (1–3 points) can be estimated with reasonable precision. Larger stories (8–21 points) carry enough unknowns that pretending to distinguish between, say, 11 and 12 points would be false accuracy.
The sequence forces an honest acknowledgement: the bigger the task, the less certain the estimate. A 21-point story is almost always a candidate for splitting.
VELOCITY AND SPRINT PLANNING
Velocity is the number of story points a team completes in a sprint. Once a team has run several sprints, their velocity stabilises into a reliable range — say, 30–40 points per sprint.
This makes sprint planning straightforward: if your velocity is 35 points and the next sprint's stories total 60 points, you know you're overcommitting. No estimation technique will ever be perfect, but velocity-based planning is consistently more accurate than hour-based planning.
COMMON MISTAKES
• Treating points as hours — once a team starts saying "1 point = 1 hour" the whole system collapses.
• Comparing velocity across teams — team A doing 50 points per sprint is not more productive than team B doing 30. Points are relative to each team's own calibration.
• Never re-calibrating — if your reference stories drift (a "3" today is nothing like the "3" from six months ago), your velocity becomes meaningless.
• Estimating too precisely — spending 20 minutes debating whether a story is a 5 or an 8 is a waste. If it's in that range, pick one and move on.