Fibonacci story points, explained

Why Fibonacci works for estimation

• Uncertainty grows with size. You can tell a 2 from a 3, but nobody can honestly tell a 20 from a 21. Wider gaps match how precise you can really be.
• It ends pointless debates. With no 6 or 7 on the table, the team has to decide whether a story is closer to a 5 or an 8, which is the question that matters.
• Big numbers act as a warning. When a story reaches 13, the scale is telling you to split it.
• It’s relative, not time. Points combine effort, complexity and risk, so a senior and a junior developer can agree on a size even if they’d take different amounts of time.

What each card usually means

Every team calibrates its own scale, but this is a sensible starting point:

111

1 points

A tiny, well-understood change. A copy tweak or a config flag you’ve flipped before.

222

2 points

Small and clear. One part of the system, no surprises expected.

333

3 points

A normal small story. A little thinking, a little testing.

555

5 points

A typical mid-sized story. Touches a couple of places or needs some investigation.

888

8 points

Big for one sprint. Several moving parts, or real uncertainty about the approach.

131313

13 points

Very large or very unclear. Usually a sign the story should be split before the sprint starts.

???

Question mark

Not enough information to estimate. Park it and get answers first.

How to calibrate your team’s scale

1. Pick a small, recently finished story that everyone remembers. Call it a 2 or a 3.
2. Find a medium story the team knows well and agree whether it was about a 5 or an 8.
3. Write both on your board as reference stories.
4. For each new story, ask “is this bigger or smaller than our reference?” rather than “how long will this take?”
5. Revisit the references every few months, as the team and codebase change.

Fibonacci vs t-shirt sizes vs hours

Common mistakes

• Turning points back into hours. “One point equals half a day” quietly brings back time estimates, and all the arguments that come with them. Keep points relative: compare stories with stories.
• Comparing velocity between teams. Each team calibrates its own scale. A 5 for one team isn’t a 5 for another, so points can’t rank teams or people.
• Splitting the difference. If votes are 3 and 13, the answer is a conversation, not an 8. Let the highest and lowest voters explain before anyone re-votes.
• Estimating huge stories. When most cards land on 13 or above, the useful outcome is a split, not a bigger number.
• Re-estimating finished work. Leave estimates alone once the work is done. Their value is in the conversation before the sprint, and in keeping velocity honest.

Questions about Fibonacci estimation