The Fibonacci scale in planning poker

Pick up almost any planning poker deck and you’ll find the same numbers: 1, 2, 3, 5, 8, 13, then a jump to 20, 40 and 100. The first stretch is the Fibonacci sequence, and the tail is a rounded-off version of it. Fibonacci planning poker has become the default scale for agile estimation, and the usual explanation has to do with how hard it is to size large pieces of work before anyone has started on them.

Why the gaps get bigger

In the Fibonacci sequence each number is the sum of the two before it: 1, 2, 3, 5, 8, 13, 21, 34, 55. At the very start the steps are uneven (1 to 2 doubles, 2 to 3 adds half), but from about 3 onward each number is roughly 1.6 times the previous one.

The usual argument for using it goes like this. Small tasks can be sized fairly precisely: most developers can tell a 1-point change, like fixing the wording of an error message, from a 2-point one, like adding a validation rule with a test. With large tasks that precision disappears. Nobody can honestly say whether a new checkout flow is 20 or 21 points, because the uncertainty grows with the size of the work. A scale whose steps grow with it matches the level of detail a team can actually offer.

People who make this argument often point to Weber’s law from psychology, which says the smallest difference we notice between two stimuli is roughly proportional to their size. You’d feel the difference between a 1 kg bag and a 2 kg bag, but probably not between 20 kg and 21 kg. Treat that as an analogy. Nobody has shown that Fibonacci is the ideal scale for software estimates, though many teams find the intuition matches their experience.

There’s also a plainly practical benefit. With fewer options at the top of the deck, the team has fewer pointless arguments. There’s no 14, so nobody debates 13 versus 14. The choice is between 13 and 20, and the difference between those two is worth a conversation.

The modified sequence: 20, 40, 100

Most decks stop following Fibonacci after 13. Instead of 21, 34 and 55 they carry 20, 40 and 100. The first planning poker deck looked different: James Grenning’s 2002 version had 1, 2, 3, 5, 7, 10 and infinity. The modified Fibonacci deck (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) became the standard later, popularized by Mike Cohn’s book Agile Estimating and Planning and his card decks.

The round numbers are a deliberate choice. Writing 34 on a story suggests you’ve measured it; writing 40 signals an order of magnitude, a rough “this is big and we don’t know how big”. At that size the round figure is the more honest one.

The standard deck, which is also what SprintPoker uses, is:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕

The special cards

0

The work is already done, or it’s so trivial it doesn’t need tracking, like changing a config value someone else has already tested. Some teams never play it.

½

For tiny tasks that still deserve a card, such as fixing a label or bumping a dependency with no breaking changes. It comes in handy when the team’s reference 1-point story is fairly substantial and something smaller needs a home.

?

“I can’t estimate this.” Treat it as information: the person needs something they don’t have. When it shows up, stop and ask what’s missing. Often it’s a quick clarification the product owner can give on the spot. Sometimes the unknown is technical, a library nobody has used or an API with no documentation, and the right move is a spike: a short, time-boxed investigation, after which the story comes back for estimation. If “?” keeps appearing on the same story after that, the story itself probably needs rewriting.

☕

“I need a break.” Estimation is mentally demanding, and the quality of the votes drops noticeably when people get tired: more 5s, fewer questions, faster agreement. Treat the coffee card as a real request and take five minutes. In a remote session it also gives someone a polite way to say they’re flagging without interrupting a colleague mid-sentence.

What to do with 40 and 100

When someone plays 40 or 100, the conversation should shift from “is this 40 or 100?” to “how do we split this?”

A story of that size is really an epic in disguise. It won’t fit comfortably in a sprint, the estimate carries a huge margin of error, and whatever number gets written down will be mostly a guess. A few ways to break it apart:

• By workflow step. “Customer can check out” becomes add to cart, enter a shipping address, pay by card, see a confirmation.
• By data or scope. “Import all historic orders” becomes orders from the last 12 months, then legacy orders.
• Happy path first. Build the main flow, then handle refunds, partial payments and failures as separate stories.
• By platform. Web first, the mobile app later.

Once each piece lands in the 1–13 range, estimate them one by one. Teams often find the pieces add up to more than the original big number, which says something about how reliable big numbers were in the first place.

A 20 sits in between. Some teams happily take 20s into a sprint; others treat anything above 13 as a cue to split. Pick a rule as a team and stick to it.

Alternatives to Fibonacci

Fibonacci isn’t the only option, and sometimes another scale suits the job better.

T-shirt sizes

XS, S, M, L, XL. These work well for early roadmap planning, when you’re sizing dozens of rough ideas and only need to know which are small and which are huge. Stakeholders who get nervous around numbers tend to find them friendlier. You can’t add T-shirt sizes up, though, so tracking velocity means mapping them to numbers eventually, and at that point you’re back to points.

Powers of two

1, 2, 4, 8, 16, 32. Each step doubles, which is easy to explain and grows a little faster than Fibonacci. The price is fewer options at the small end, with nothing between 2 and 4, and for many teams that’s exactly where most of the backlog sits.

Linear scales

1 to 10, or 1 to 5. They look intuitive, but they offer false precision at the top end. Is it a 7 or an 8? Nobody can really tell, and the team ends up arguing about a difference it has no way to measure.

Which to choose

For sprint-level work that feeds velocity, the modified Fibonacci deck is a safe default: most people already know it, and its gaps follow the way uncertainty grows. T-shirt sizes suit early, rough sizing of epics and roadmap items. If your team has a real reason to prefer powers of two, use them, but keep the scale fixed, because switching mid-project breaks your velocity history.

Whatever scale you pick, the numbers only mean something relative to the team’s own reference stories. How to choose those, and why points beat hours, is covered in the story points guide; the rules of a round are in the planning poker guide.