Fibonacci Estimation for Planning Poker

Open almost any planning poker deck and you will see the same numbers: 1, 2, 3, 5, 8, 13, 21. That is a modified Fibonacci sequence, where each value is roughly the sum of the two before it. Agile teams did not pick it for mathematical elegance — they picked it because the widening gaps mirror how estimation uncertainty actually behaves.

Why not just use 1 through 10?

A linear scale invites false precision. On a 1–10 scale, people argue about whether a story is a 6 or a 7 — a distinction nobody can actually feel. Fibonacci removes those meaningless debates. Once a story is clearly bigger than a 5, your only options are 8 or 13, which forces a real decision instead of hair-splitting.

The growing gaps also encode a truth about big work: the larger something is, the less precisely you can estimate it. You can tell a 2 from a 3. You cannot meaningfully tell a 19 from a 21 — so the scale does not offer you the option.

What each number tends to mean

Points are relative, so these are not universal — but this is a common starting calibration teams recognize:

Anchor to a reference story, not to hours

The scale only works if the whole team shares a mental yardstick. Pick one recently completed story that everyone agrees was a “3” and keep it as a reference. New estimates then become comparisons: “Is this bigger or smaller than our reference 3?” This is far more reliable than trying to convert points to hours — see story points explained for why time and points should stay decoupled.

What to do with a 13 or higher

Treat 13 as a warning light. A story that large usually hides multiple stories, and large items are the ones most likely to spill across sprints. Split it by workflow steps, by acceptance criteria, or by happy-path-first. For example, “Add password reset” (a 13) might split into:

1. Request-reset form and email dispatch (5).
2. Token validation and password update (5).
3. Rate limiting and abuse protection (3).

Three well-understood stories are easier to estimate, review, and finish than one vague 13.

Common Fibonacci estimation mistakes

• Re-inventing hours. If “1 point = 1 day” for your team, you have quietly switched back to time estimation.
• Adding half-points. There is no 4 and no 6 for a reason. Round to the nearest card.
• Letting the scale drift. Without a reference story, today's 5 becomes next month's 8, and velocity stops meaning anything.
• Committing to 13s. Pulling an unsplit 13 into a sprint is the most common cause of carryover.

Frequently asked questions

Do the numbers have to be exactly Fibonacci?

No. The modified sequence (which rounds 8→8, 13→13, 20/21, 40, 100) is what most decks ship. The important property is that the gaps grow, not the exact values.

Can we convert Fibonacci points to a time estimate?

Only in aggregate, through velocity — never per story. A team that completes ~24 points a sprint can forecast a backlog, but no single point equals a fixed number of hours.

Should we use T-shirt sizes instead?

For early, coarse sizing of epics, T-shirt sizing can be faster. For sprint-level stories, Fibonacci gives you the granularity you need to forecast.

Estimate with a Fibonacci deck now

PlanITPoker ships with a Fibonacci deck (1, 2, 3, 5, 8, 13, 21, 34) plus ? and coffee cards, and shows the vote distribution the moment you reveal. Create a free room and try it with your next backlog item.