Story points & time

The questions about story points that don't go away. Direct answers, with the failure modes named.

Story points are a relative-effort measure. You size a backlog item against a reference story — "this is about twice that one" — instead of guessing how many hours it will take. One number carries effort, complexity, and uncertainty together, which is exactly why it survives contact with reality better than an hour estimate does.

Most teams vote on a Fibonacci-style scale — 1, 2, 3, 5, 8, 13 — in a round of Planning Poker. The gaps widen on purpose: the bigger the work, the less anyone really knows, so the scale stops pretending you can tell a 9 from a 10. Add up the points a team finishes each sprint and you get velocity — the one forecasting input points are actually meant to produce.

The single biggest failure mode is the team that starts converting points back into hours, days, or person-weeks — at which point it has thrown away the property the technique exists to give it. The pages below cover the conversion-trap questions, the "should we estimate this?" questions, and the work types that get systematically under- or over-sized.

The conversion trap

"Should we estimate X?"

When to revisit an estimate

When scale gets in the way

Adjacent: other estimation techniques for the alternatives to points; common mistakes for the in-session failures these questions usually surface.