How to Estimate Story Points

Story points are relative, not absolute

A story point doesn't map to a fixed number of hours. It's a relative measure: if a team agrees a login form is a 2, and a new story looks roughly three times as involved — more edge cases, an external API dependency, more testing surface — it's probably a 5 or an 8, regardless of whether the login form actually took four hours or fourteen.

This matters because effort, complexity, and uncertainty don't scale in a straight line with time. Two stories can take the same number of hours to build and still deserve very different point values, if one of them is well-understood, low-risk work and the other is a first attempt at something the team has never built before.

Why the Fibonacci sequence

Most teams estimate on a Fibonacci-like scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. The gaps get wider as the numbers get bigger, which is the entire point of the sequence. Estimation confidence gets wider too — a team can usually agree confidently whether something is a 2 or a 3, but a real argument over whether a story is a 19 or a 21 is time spent manufacturing precision the team doesn't actually have.

A linear 1-through-10 scale doesn't have this property — it invites exactly that kind of false-precision argument at every point on the scale, not just the high end. That's the practical case for Fibonacci over a plain integer sequence: it structurally discourages debating detail the team can't actually resolve. Teams typically size and vote on these numbers using planning poker, which is built around this exact deck.

Story points vs. other estimation techniques

Story points aren't the only relative-sizing technique, and it's worth knowing the alternatives:

• T-shirt sizing (XS/S/M/L/XL)

  Faster and coarser than story points — useful for a quick backlog triage, but too imprecise to drive sprint planning on its own. Many teams use it to rough-cut a large backlog before running planning poker on the stories that make the cut.

• Dot voting

  Good for prioritization (which stories matter most), not sizing (how much effort a story takes) — a different question entirely, and easy to conflate with estimation.

• Raw hour estimates

  Feels more concrete, but tends to be treated as a promise rather than a guess, and doesn't age well as a story's scope shifts mid-sprint.

From points to a real plan: velocity

Story points only become useful for planning once a team has a velocity — the average number of points it completes per sprint, measured over several sprints rather than assumed up front. A team that completes 30 points a sprint plans its next sprint around roughly 30 points of work, not whatever number a different team uses. Velocity is a team-specific number; comparing it across teams is close to meaningless, since two teams almost never calibrate their 3s and their 8s the same way.

Common failure modes

Treating points as disguised hours. The moment a team starts converting points to hours at a fixed rate — "1 point = 4 hours" — the relative scale collapses back into an absolute one, and estimation sessions turn into time negotiations instead of effort discussions.

Velocity gaming. If velocity becomes a performance metric, teams learn to inflate estimates rather than improve delivery. Velocity is a planning input, not a target.

Estimating without discussion. The estimate is a byproduct of the team building a shared understanding of the work — not the goal itself. A vote that converges instantly on a story nobody actually understood yet is a warning sign, not a win.

Stories too big to size confidently. If a team keeps landing on 20s, 40s, or the "I don't know" card, that's usually a signal the story needs to be split, not estimated harder.

Frequently asked questions

What is a story point?

A story point is a relative, unitless measure of how much effort a piece of work takes — accounting for complexity, uncertainty, and volume of work — compared to other stories the team has already sized. It is not a measure of time.

Why use Fibonacci numbers for story points?

The widening gaps between Fibonacci-like numbers (1, 2, 3, 5, 8, 13, 20, 40, 100) mirror how estimation confidence actually works: teams can tell a 2 from a 3 reasonably reliably, but arguing over whether something is a 19 or a 21 is false precision. The scale forces a decision between meaningfully different buckets instead.

Are story points the same as hours?

No, and treating them as a disguised hours conversion is the single most common way teams get estimation wrong. Story points measure relative effort; velocity (points completed per sprint) is what translates that into a real-world planning horizon, and it's specific to each team.

How many story points should a sprint have?

There's no universal number — it depends entirely on a team's own velocity, measured over several sprints. A team that averages 30 points per sprint should plan for roughly 30 points, not whatever number a different team down the hall uses.