Planning Poker Fibonacci Sequence

Why Fibonacci?

Planning Poker decks use numbers loosely based on the Fibonacci sequence, where each number is roughly the sum of the two before it. Applied to estimation, the gaps between cards grow as the numbers grow - which matches how story point estimation actually works in practice: teams can be fairly precise about small stories, but precision about large, uncertain ones is mostly an illusion.

The standard sequence

The most common Planning Poker deck is:

0, 1, 2, 3, 5, 8, 13, 21, 34

Plus a small set of non-numeric cards most teams add: a question mark for "not enough information to estimate," and sometimes a coffee cup for "let's take a break, this discussion needs it."

Modified Fibonacci

Many teams use a rounded "modified Fibonacci" scale instead of the strict sequence:

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

The values above 13 are rounded to numbers that are easier to say and compare at a glance (20 instead of 21, 40 instead of 34) - the exact math stops mattering once a story is that large and uncertain anyway. Some teams also cap the deck at 13 or 21 entirely, treating anything bigger as a sign the story needs to be split rather than estimated as one unit.

Why uncertainty grows with the number

A team can usually defend the difference between a 2 and a 3 - it's a small, concrete gap. Try to defend the difference between a 20 and a 21, though, and there's nothing to say: at that size, nobody actually knows the work to that precision. Widening gaps at the high end stop teams from wasting time debating a distinction that isn't real, and nudge them toward the more useful conversation - "is this actually one story, or should it be split?"

Which scale should your team use?

The strict sequence (1, 2, 3, 5, 8, 13, 21...) works well for teams that like clean math and don't mind odd-looking numbers like 21 or 34 on a burndown chart. The modified scale (with 20, 40, 100) tends to suit teams that report points to stakeholders who aren't used to reading raw Fibonacci numbers - it looks more like a normal scale while keeping the same widening-gap behavior. Either way, the number that matters is relative size, not the specific digit.

Example

A small bug fix that touches one file might get a 1. A new form field with validation might get a 3. A new authentication flow that touches the frontend, backend, and email delivery might land on 13 - and if the team's votes for that story land on both 8 and 21, that spread itself is useful information: it usually means the story needs to be broken down before anyone can estimate it with confidence. See Planning Poker examples for a full walkthrough of a round like this.

FAQ