Fibonacci Story Points: Why the Gaps Get Wider
Fibonacci story points use a modified version of the mathematical Fibonacci sequence - 0, 1, 2, 3, 5, 8, 13, 21 - as the scale for sizing backlog items, because the widening gaps between numbers match how estimation uncertainty naturally grows with size. It's the default scale for most Scrum teams, and understanding why it works makes it much easier to use well.
The sequence, and the one modification
The real Fibonacci sequence is 0, 1, 1, 2, 3, 5, 8, 13, 21, 34... - each number is the sum of the two before it. Agile estimation drops the repeated 1 (since two identical values add nothing to a voting deck) and usually stops around 21, adding a ? card for "not estimable yet" instead of continuing to 34, 55, and beyond. The result is the deck most teams actually use:
0, 1, 2, 3, 5, 8, 13, 21, ?
Zero deserves a mention: it's for work that's real but trivially small - a one-line config change, a typo fix - small enough that counting it as a full "1" would inflate the team's velocity for no reason.
Why the gaps widen on purpose
This is the entire reason Fibonacci beats a simple 1-10 scale for estimation. Look at the differences between consecutive values: 1, 1, 1, 2, 3, 5, 8. Near the bottom, the gaps are tiny - a 1 and a 2 are close together, because at small sizes people can genuinely tell the difference. Near the top, the gaps are huge - 13 to 21 is an eight-point jump, because at that size nobody can reliably distinguish "this big" from "this much bigger."
A linear scale (1, 2, 3, 4, 5, 6, 7, 8...) lies about this. It implies a team can tell a 6-point story from a 7-point story with the same confidence it can tell a 1 from a 2 - and it can't. Forcing that false choice is exactly the "precision theater" anti-pattern covered in estimation anti-patterns: time spent debating a distinction the team has no real basis for making.
The underlying principle has a name outside software: the Weber-Fechner law, from 19th-century psychophysics, describes how humans perceive differences in stimulus intensity proportionally rather than absolutely - the difference between holding a 1kg and 2kg weight is obvious, but the difference between 21kg and 22kg is not, even though both pairs differ by exactly 1kg. Fibonacci's widening gaps are a rough fit to that same proportional-perception curve, applied to effort instead of weight.
What each value tends to mean
These are illustrations, not standards - see the complete story points guide for why cross-team comparison never works - but most teams converge on something close to this:
| Points | Rough meaning | Example |
|---|---|---|
| 0 | Trivial, barely worth logging | Fix a typo, bump a config value |
| 1 | Tiny, well-understood | Add a single validation rule |
| 2 | Small, clear path | A straightforward CRUD field |
| 3 | Solid, still clear | A new form with a few states |
| 5 | Meaningful complexity or size | A new API integration with known docs |
| 8 | Large - worth watching | Touches several systems, some unknowns |
| 13 | Near the ceiling | Should usually be split before a sprint |
| 21 / ? | Not a real estimate | Too big to size - split it |
Fibonacci variants you'll see in the wild
Not every "Fibonacci deck" is identical, and the differences are worth knowing so a mismatch doesn't derail a session:
- The modified sequence (most common): 0, 1, 2, 3, 5, 8, 13, 21, ? - drops the repeated 1, adds a zero and a question mark. This is what Rolia Estimation and most planning-poker tools ship by default.
- The "pure" sequence: 1, 2, 3, 5, 8, 13, 21, 34 - closer to the mathematical original, sometimes preferred by teams who find the double meaning of "0 points but real work" confusing.
- Extended decks: some tools add 40, 100, or an infinity symbol above 21 for epic-level sizing. In practice, anything that would land above 21 in a healthy backlog should be split rather than given a bigger number - an extended deck can quietly enable the habit of estimating stories that were never ready.
- Special non-numeric cards: a coffee-cup card ("let's take a break") and a question-mark card ("I have no idea") show up in most physical decks. They're not really estimates - they're structured ways to say something other than a number, which keeps the ritual honest instead of forcing a guess.
Fibonacci and velocity
Because Fibonacci points are summable, they feed directly into velocity - a rolling average of points completed per sprint becomes the team's basis for planning the next one. This is a real practical advantage over t-shirt sizes or other non-numeric scales, which need an explicit size-to-number mapping before they can be summed at all. It's also the reason Fibonacci dominates at the sprint-ready end of a backlog even on teams that use a coarser scale further out: the numbers need to add up cleanly by the time they're driving a sprint commitment.
A short calibration example
Say a team's very first estimation session produces a 5 for "add CSV export to the reports page." Six months later, a similarly-scoped story - "add CSV export to the audit log page" - comes up. If the team still has genuine context on the original story ("that took about this long, and this one looks about the same"), a fast 5 is a well-calibrated estimate, not a coincidence. If nobody remembers the reference anymore, that's the signal to run a short recalibration: look at five or six recently completed stories with their points, and ask whether the numbers still feel right. The full process is in calibrating your estimation scale.
Why not just use hours divided by a constant?
A tempting shortcut: "let's just say 1 point = 4 hours, and multiply." This defeats the entire point of the scale. If points were a fixed multiple of hours, they'd carry no more information than hours do - same false precision, same individual accountability problems, just wearing a different unit. The full argument, including why hours actively make estimation worse, is in story points vs hours.
Calibrating your team's Fibonacci scale
Fibonacci numbers mean nothing until anchored to real work. The process - pick a reference story, call it your 3 or 5, compare everything else to it, re-anchor when the team or codebase changes significantly - is covered in full in calibrating your estimation scale. Skipping this step is the single most common reason a new team's Fibonacci estimates feel arbitrary: the scale is real, but it hasn't been connected to anything yet.
When Fibonacci isn't the right scale
Fibonacci earns its keep at the sprint-planning level, where the team has enough context to argue meaningfully about a 5 versus an 8. It's the wrong tool for two situations:
- Roadmap-level, rough sizing. Arguing Fibonacci values six months before anything is refined is false precision at an earlier stage - t-shirt sizing fits better there.
- Very large, mostly-unrefined backlogs. Running Fibonacci rounds on 80 items is how estimation becomes the meeting everyone dreads - affinity estimation or the bucket system size a backlog like that in a fraction of the time. Both are covered in the full technique comparison.
Common mistakes teams make with Fibonacci
- Splitting hairs on 5-vs-8, then never noticing the same discipline is missing at 1-vs-2. The scale is coarse at the top for a reason; keep the debate energy proportional to how much the number actually matters.
- Treating 13 as a normal size instead of a warning sign. A backlog with a healthy flow of stories rarely needs 13s in a sprint - if they show up often, refinement is happening too late.
- Quietly extending the deck upward instead of splitting. Adding a 34 or 55 card solves the symptom (a story that won't fit the scale) while leaving the actual cause (an unrefined story) untouched.
- Forgetting the deck is relative, not absolute. A borrowed reference story from a blog post, a course, or a previous employer means nothing to a team that hasn't calibrated its own scale against its own work.
Most of these fold into the broader catalog in estimation anti-patterns - Fibonacci just makes a couple of them easier to spot early.
Play a round with a real Fibonacci deck
The fastest way to feel why the gaps matter is to vote a few rounds yourself. Create a free room with the Fibonacci deck, size five real stories, and notice how naturally the conversation gravitates to "is this a 5 or an 8" instead of hunting for a number between two nearly identical values. Prefer a physical deck? Print one for free.