Why agile teams estimate with the Fibonacci sequence

Agile teams estimate with the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21 and so on) because the gaps between the numbers grow as the numbers grow. With Fibonacci story points, small items can be told apart precisely and large items only roughly, which matches reality: the bigger and vaguer a piece of work, the less anyone really knows about it. A scale with widening gaps only asks for the precision you actually have.

The sequence has no special powers, though. Mike Cohn ran teams on a simple doubling scale as well and found both worked about equally well. What matters is a short list of values whose steps grow in proportion to size. Many planning poker decks use a modified version, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100, and this guide explains why, along with what to do when an item lands on 21 or more.

What is the Fibonacci sequence?

In the Fibonacci sequence each number is the sum of the two before it: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55 and onwards. It is named after Leonardo of Pisa, known as Fibonacci, whose book Liber abaci (1202) included a puzzle about breeding rabbits that produces the series. Estimation decks drop the repeated 1, so the cards read:

• 1
• 2
• 3
• 5
• 8
• 13
• 21

The useful property for estimators is the ratio between neighbours. As the sequence goes on, each number gets closer to about 1.618 times the one before it, the so-called golden ratio. From 3 upwards, every step is roughly 60% bigger than the last:

So the absolute gaps widen (1, 1, 2, 3, 5, 8) while the relative jump stays roughly constant. That combination is what makes the scale work for estimation.

Why growing gaps suit estimation

Bigger items hide more uncertainty

A 2-point item, such as adding a field to a form, has few unknowns. A 13-point item, such as moving checkout to a new payment provider, has many: an unfamiliar API, data to migrate and edge cases nobody has thought of yet. The honest estimate for the big item is a wide range, and a scale that jumps from 8 to 13 to 21 builds that range into the numbers.

Software estimation has a well-known picture of this idea, the cone of uncertainty. Barry Boehm’s 1981 book Software Engineering Economics showed early estimates as being within a factor of four either way, 80% of the time, with the range narrowing as a project learns more, and Steve McConnell later popularised the diagram. As Laurent Bossavit has pointed out, Boehm’s ranges were set by judgement rather than measured, so treat the cone as a useful picture rather than a law. The principle still holds: the less you know, the wider your estimate should be.

Weber’s law, stated carefully

Mike Cohn links the Fibonacci scale to Weber’s law, an idea from 19th-century research on perception. Ernst Weber proposed in the 1830s that the smallest change in a stimulus we can notice is a constant fraction of the original stimulus, not a fixed amount. Light a second candle in a dark room and everyone notices; add one candle to a room already lit by fifty and nobody does.

If judgements of effort behave in a similar way, a team can reliably tell a 3 from a 5 but not a 13 from a 14, and a scale whose steps grow in proportion stops you claiming distinctions you can’t make. That “if” matters. Weber’s law comes from studies of perception, such as noticing changes in brightness, so applying it to software estimates is an analogy, not something the law itself shows. Cohn also notes that the law doesn’t hold at extreme values. Treat it as a helpful way to think about the scale, not as proof that Fibonacci is the best one.

Fewer choices mean faster agreement

A coarse scale also saves time. With only 1, 2, 3, 5, 8 and 13 to choose from, nobody spends five minutes arguing whether an item is a 6 or a 7, a distinction that is hard to make with any confidence. The gaps were there from the start: James Grenning’s original 2002 planning poker deck had cards for 1, 2, 3, 5, 7 and 10, meant as ideal days or unitless numbers, plus infinity. In his words, “As the estimates get longer, the precision goes down.”

The modified Fibonacci scale: why 20, 40 and 100

Many decks don’t use the pure sequence. A common modified version looks like this:

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

• 20 instead of 21. Cohn’s teams found that an estimate of 21 implied a precision they couldn’t support, so they used 20 instead.
• 40 and 100 instead of 34, 55 and 89. These jump much further than 60% (by 100% and 150%). They are deliberately vague, and work better as “this is big and we don’t understand it yet” than as sizes to add up.
• 0 and ½. For trivial changes and tiny items, so a team that slices work small isn’t forced to call everything a 1.
• ? For “I can’t estimate this yet”, which is valuable information in itself.

Decks that follow the pure sequence instead carry on to 34, 55 and 89. Either works, as long as the team reads the big cards as warnings rather than as numbers to plan with.

How to use Fibonacci story points well

The scale only helps if the team uses it consistently. A few habits make the difference:

1. Anchor on reference stories. Agree a few finished items as your typical 2, 3, 5 and 8, and compare new work with them. Our guide to setting a baseline with reference stories shows how.
2. Treat each value as a bucket. A 13 means “bigger than 8, up to 13”. An item that feels like a 10 goes in the 13 bucket. Rounding up keeps forecasts honest.
3. Don’t average to off-scale numbers. A round of 5, 5, 8 and 8 is a conversation, not a 6.5. Discuss what separates the votes, vote again and settle on a value from the scale.
4. Keep most items between 1 and 13. Mike Cohn notes evidence that people estimate most reliably within about one order of magnitude, so a backlog full of 20s and 40s needs splitting, not more estimating.

For the bigger picture of what the numbers mean, and what they don’t, see story points explained.

What to do with items estimated at 21 or more

When an item lands on 21, 40, 100 or infinity, treat the vote as a signal, not an estimate. It usually means the item is several stories wearing one title, that the team doesn’t understand it yet, or both. Grenning’s advice in 2002 was blunt: if a story is longer than two weeks, play the infinity card and make the customer split it.

• Split it. Break the item into thin slices that each deliver something testable. Our guide on how to split user stories has patterns that work.
• Spike it. If the size is unknown because a question is unanswered, time-box a short investigation, then estimate the follow-up work.
• Clarify it. Sometimes the product owner can cut scope on the spot once the team explains what makes the item big.
• Park it at roadmap level. If it isn’t needed for several sprints, a rough size is enough for now.

Here is a typical example. “Customers can manage their subscription” gets votes of 20, 40, 40 and 100. Split, it becomes “See current plan and renewal date” (3), “Upgrade or downgrade with pro-rata billing” (8), “Cancel with a reason” (3), “Pause for one month” (5) and “Send plan-change emails” (3). The pieces add up to 22 points, which says nothing precise about the original item, but each piece can now be understood, estimated and delivered on its own. Keep the 40s and 100s themselves out of sprint plans and out of velocity.

Alternatives to the Fibonacci scale

Fibonacci is popular, not compulsory. The best scale is the one your team uses consistently. The common options:

Cohn’s own comparison, mentioned above, found no clear evidence that either Fibonacci or doubling was better. His slight preference for Fibonacci came from watching discussions: with doubling, teams argued about whether an item was exactly twice another, while with Fibonacci they talked about the work, though he admits he had no way of measuring that. If your team prefers sizes to numbers, our guide to T-shirt sizing covers when that works and when to move on, and planning poker cards and decks explained walks through every common deck.

On planningpoker.org SprintPoker decks include Fibonacci (0 to 89), Fibonacci (1 to 89), Small Fibonacci (0.5 to 13), Linear (1 to 10), Hours (1 to 40), T-shirt sizes, and, in sessions on a Laya board, that board’s own scale, such as 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Every deck has a ? card, which counts as a vote but never towards the average.