The Fibonacci scale in planning poker
The short answer
Planning poker decks use 1, 2, 3, 5, 8, 13, 21 rather than 1 to 10 because estimates get less accurate as the work gets bigger, and the scale should say so.
A team can genuinely distinguish a two-point item from a three-point one. Nobody can distinguish a 21 from a 22. A linear scale offers that distinction anyway, and a room will spend real minutes arguing over it. The Fibonacci gaps remove the option: the next value up from 13 is 21, so the question stops being "is this 21 or 22" and becomes "is this closer to 13 or to 21" — which is a question the team can actually answer.
The sequence
Each number is the sum of the two before it:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89
The ratio between neighbours settles at roughly 1.6, so every step up is about 60% bigger than the last. That constant proportional jump is the useful property, not the mathematics — the sequence just happens to produce it.
Estimation decks add three cards that are not part of the sequence:
- 0 — already done, or so small it is not worth tracking.
- ? — cannot be estimated yet. Usually needs a spike or a decision first.
- ☕ — a request for a break. Not an estimate, and it does not count toward one.
What the values mean in practice
The numbers are relative, so they only acquire meaning once the team fixes a reference item. Pick something already finished, call it a 3, and estimate everything against it. The rough shape most teams converge on:
| Points | Typical meaning |
|---|---|
| 1 | Trivial and fully understood. A config change, a copy fix. |
| 2 | Small and clear. One place to change, obvious how to test it. |
| 3 | The reference. A normal, well-understood piece of work. |
| 5 | Understood but larger, or touches more than one component. |
| 8 | Substantial. Some uncertainty, likely more than one person involved. |
| 13 | Big and partly unclear. Most teams treat this as the last honest value. |
| 21+ | The team is saying it does not understand the item. Split it. |
The most useful line in that table is the last one. High Fibonacci values are a signal, not a size — they exist so a team can say "this is too vague to estimate" using a number rather than an argument.
Fibonacci, modified Fibonacci and T-shirts
| Deck | Values | What it changes |
|---|---|---|
| Fibonacci | 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, ☕ | The strict sequence. Awkward large numbers, which some teams find harder to say out loud. |
| Modified Fibonacci | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕ | Rounds the top values and adds a half point. Same behaviour, easier vocabulary. |
| T-shirt sizes | XXS, XS, S, M, L, XL, XXL, ?, ☕ | Identical logic, no arithmetic. Cannot be summed, which stops points being read as a schedule. |
| Powers of two | 0, 1, 2, 4, 8, 16, 32, 64, ?, ☕ | Doubling instead of 1.6×. Coarser, useful when items differ by orders of magnitude. |
If the team wants to sum estimates and watch velocity settle over a few sprints, use Fibonacci or the modified version. If the team is new to estimation, or if stakeholders reliably turn "8" into "eight days", T-shirt sizes remove that failure mode by refusing to be arithmetic.
Two things that break the scale
Converting points to hours. Once the team publishes a rate — "a point is half a day" — estimation stops being about relative size and becomes a negotiation over deadlines. Every subsequent estimate is a hedge, and the numbers lose the meaning that made them useful.
Comparing points between teams. The scale is calibrated against one team's reference item. Two teams estimating identical work will land on different numbers, and both are correct. Any metric that compares them rewards whoever inflates their scale.
Using it in QRetro
Fibonacci is the default deck when you open a game, and modified Fibonacci, T-shirt sizes and powers of two are one dropdown away. Cards stay hidden until everyone has voted, and the estimate is computed from the revealed votes rather than set by hand.
Start with how a planning poker session runs, or connect a tracker so the backlog does not have to be retyped — see planning poker with Jira.
