Why agile estimation uses the Fibonacci sequence
Fibonacci estimation uses numbers like 1, 2, 3, 5, 8 and 13 to size work. The growing gaps between values are the whole point: they match how uncertainty grows with size.
Fibonacci estimation is the practice of sizing agile work using numbers from the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 and so on, where each number is the sum of the two before it. It is the most common scale for story points and the default deck in most planning poker tools. This guide explains why the sequence works so well, how the modified Fibonacci scale differs, and what to do when a story is too big to estimate.
Why not just use 1 to 10?
Imagine estimating with every number from 1 to 20. A team debates whether a story is a 12 or a 13. That debate is a waste of time: nobody can tell the difference between a 12 and a 13 at the estimation stage, so the extra precision is fake.
A linear scale invites exactly this kind of argument. The Fibonacci sequence removes it by offering fewer options as numbers get bigger. Between 8 and 13 there is nothing to choose from, so the team only has to answer a simpler question: "Is this closer to 8 or to 13?"
The intuition behind it: Weber's law
In psychology, Weber's law describes how we perceive differences. The smallest change we can notice is roughly proportional to the size of the thing we are comparing. You can easily tell a 1 kg bag from a 2 kg bag, but a 20 kg bag and a 21 kg bag feel the same, even though the absolute difference is identical.
Estimation works the same way. Telling a 1-point story from a 2-point story is easy. Telling a 20-point story from a 21-point story is not. A scale where each step is about 60% bigger than the previous one (the Fibonacci ratio) gives every step a difference that people can actually perceive.
Uncertainty grows with size
Small stories are usually well understood. "Change the label on the save button" holds few surprises. Large stories hide unknowns: integrations that behave differently than documented, edge cases nobody thought of, dependencies on other teams.
The widening gaps in the Fibonacci sequence reflect that. A 2 implies "we're fairly sure about this". A 13 implies "this is big, and we could be off by quite a lot". The scale communicates confidence along with size, which a linear scale cannot do.
Here is an example. A team uses "Let users change their display name" as its reference 2. Someone suggests "Add password reset by email" is a 4. On a Fibonacci scale, 4 is not available, so the team has to decide: is it closer to the reference (3) or clearly more than double (5)? Thinking about the token, email template, expiry rule and new page, they choose 5. The constraint forced a more honest conversation.
The modified Fibonacci scale
Many teams use a modified Fibonacci scale popularized by Mike Cohn's planning poker cards:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
The changes from the pure sequence are practical:
- 0 is for work that is trivial or already done, such as a config change that takes minutes.
- ½ is for very small tasks that still deserve to be counted.
- 20, 40 and 100 replace 21, 34, 55 and 89. Round numbers avoid implying precision the team does not have. Nobody can honestly say a story is exactly 34 rather than 40.
Decks often add a ? card ("I can't estimate this yet") and a coffee card ("I need a break"). In Scrum Poker you can choose between a Fibonacci deck, a modified Fibonacci deck, t-shirt sizes, powers of 2 or your own custom values, and turn the coffee card on or off.
Fibonacci vs other scales
| Scale | Example values | Good for |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Story points for sprint-sized work |
| Modified Fibonacci | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Story points with room for tiny and very large items |
| Powers of 2 | 1, 2, 4, 8, 16, 32 | Teams that like doubling as a mental model |
| T-shirt sizes | XS, S, M, L, XL, XXL | Early backlog and roadmap sizing |
All of these share the key property: gaps grow with size. The choice between them matters less than using one consistently.
When a story is too big to estimate
If a story lands on 40 or 100, the honest message is "we don't really know". That is useful information, but it is not an estimate you can plan a sprint around. The right response is usually to split the story.
Common ways to split:
- By workflow step: "Request password reset" and "Set new password from link" instead of one large reset story.
- By data or user type: support email login first, add a third-party identity provider later.
- By happy path and edge cases: deliver the main flow, then handle expired links, repeated requests and error messages.
- With a spike: if the uncertainty is technical, timebox a short investigation and estimate afterwards.
Many teams set a rule of thumb: anything above 13 does not go into a sprint until it has been split. Your threshold may differ, but having one avoids carrying large, vague stories from sprint to sprint.
Practical tips
- Keep reference stories at a few points on the scale (for example a 1, a 3 and an 8) so new stories have something close to compare against.
- Do not average Fibonacci votes into numbers that are not on the scale. If the team is split between 5 and 8, discuss and choose one.
- Remember that the numbers are relative. A 5 is about the size of other 5s, not a number of days.
To see how Fibonacci estimation compares with methods that use no numbers at all, read our guide to agile estimation techniques.
Frequently asked questions
Why is the Fibonacci sequence used for story points?
Because the gaps between values grow as numbers get bigger, which matches how uncertainty grows with the size of the work. It also removes pointless debates like 12 versus 13.
What is the modified Fibonacci scale?
It is a variation commonly used in planning poker: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. It adds values for tiny items and replaces large Fibonacci numbers with rounder ones that do not imply false precision.
What should we do with a story estimated at 40 or 100?
Treat it as a signal that the story is too large or too unclear to plan. Split it into smaller stories, or run a short timeboxed spike to reduce uncertainty, then estimate again.
Can we average Fibonacci estimates?
Averages are useful to see where the team stands, but the final estimate should be a value on the scale. If votes are split, discuss the reasons and agree on one card.