The Fibonacci Scale in Planning Poker, Explained

Why Fibonacci? Estimates are relative, and uncertainty grows with size

Planning poker doesn't estimate hours. It estimates relative size: this story compared to that story. A story twice as big gets roughly twice the points. The trouble is precision: a team can confidently tell a 2 from a 3, but nobody can honestly tell a 17 from an 18. The Fibonacci scale builds that honesty in — the gaps between numbers grow as the numbers grow (1, 2, 3, 5, 8, 13, 21), so the scale offers fine detail where you're confident and coarse steps where you're not. Many teams use a modified scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) with the same idea: beyond a certain size, precision is fiction.

What the sizes mean in practice

• 0–1: Trivial. A text change, a config flag, an obvious one-liner with no unknowns.
• 2: Small and well understood. The team has done this exact shape of work before.
• 3: Small, with one wrinkle — a dependency, an edge case, a bit of research.
• 5: A solid, normal story. Some complexity, no scary unknowns.
• 8: Large or uncertain. Touching several parts of the system, or one part nobody knows well.
• 13: Very large. Almost certainly more than one person's sprint work — strongly consider splitting.
• 21 and up: Not a story. It's an epic wearing a story's clothes. Split it before estimating again.

Two special cards complete most decks: "?" (I don't have enough information to estimate) and the coffee cup (I need a break / this discussion has gone long).

Worked examples: what a 2, a 5 and a 13 look like

Anchor everything to one reference story the whole team knows (many teams pick a familiar 2 or 3) and compare against it.

• "Send a password-reset email" — 2. Known pattern, one template, one endpoint, standard tests.
• "Add social login (Google OAuth)" — 5. Known approach, but provider quirks, account-linking edge cases and extra test paths.
• "Add faceted search with filters" — 8. Indexing choices, UI state, performance questions.
• "Migrate billing to a new payment provider" — 13, then split. Data migration, webhooks, refunds, compliance: at least four stories hiding in one line.

The numbers only mean something inside your team. A 5 is not five hours and not five days — it's "about the size of the OAuth story." That is a feature: points stay stable even as the team's speed changes.

How a planning poker round works

1. The product owner reads the story and answers questions until the work is understood.
2. Everyone picks a card privately — no showing, no anchoring on the senior voice.
3. Cards reveal simultaneously. Agreement (or near-agreement) means the estimate stands.
4. If estimates diverge, the highest and lowest voters explain their reasoning — this is where hidden assumptions and risks surface — then the team re-votes.
5. Two rounds without convergence usually means the story is unclear or too big: clarify or split, then estimate again.

Happy Backlog's free planning poker runs exactly this flow in the browser: one link, private Fibonacci voting, simultaneous reveal, no signup.

Story points are not hours

Converting points to hours ("a point is about four hours") quietly destroys the system: estimates become commitments, people pad, and velocity becomes a performance metric instead of a planning tool. Points measure relative size and complexity. Velocity — how many points the team actually completes per sprint — turns that into a forecast without ever pricing a story in hours.

Fibonacci vs t-shirt sizing

T-shirt sizes (XS, S, M, L, XL) are the same idea with labels instead of numbers: great for early, rough roadmap estimates and for mixed audiences. Fibonacci points win for sprint-level estimation because they feed velocity tracking. Many teams use both: t-shirts at roadmap time, points at refinement.

Frequently asked questions