How Story Points and the Fibonacci Scale Work

What story points represent

A story point is a unit of relative size. When a team gives a story 5 points, it is saying “this is noticeably bigger than our 3-point stories, and smaller than our 8s” — not “this will take five hours” or “five days”.

That size usually blends three things the team weighs together:

• Effort — how much work there is to do.
• Complexity — how hard that work is to get right.
• Uncertainty — how much is still unknown.

The separation from time is historical and deliberate. Ron Jeffries, one of the originators of Extreme Programming, describes how early XP teams estimated in “ideal days”, and how stakeholders kept hearing “3 days” as a promise. Dropping the unit and keeping just the number is roughly how “points” came about — he has since written that he “may have invented story points, and if I did, I’m sorry now.”^[1]

Why teams estimate relatively

People are much better at comparing two things than at sizing one thing in isolation. “Is this bigger or smaller than the login change we did last month?” is an easier and more reliable question than “how many hours will this take?”

Relative estimation leans on that. The team keeps a few well-understood stories as references and sizes new work by comparison. The numbers stay consistent within the team even when individual people work at different speeds, because everyone is comparing against the same examples rather than their own personal pace.

The Fibonacci scale

Most teams don’t estimate on a straight 1-to-10 line. They use a sequence based on the Fibonacci numbers, where each value is the sum of the two before it:

1 · 2 · 3 · 5 · 8 · 13 · 21

The gaps grow as the numbers grow, and that is the point. Telling a 2 from a 3 is realistic; telling a 14 from a 15 is not. After the first few steps, each Fibonacci number is roughly 60% larger than the one before, so every step up is a similar proportional jump. Mike Cohn connects this to Weber’s law, the observation that we perceive differences relative to size rather than in absolute terms.^[2]

Teams vary the scale. Planning poker, first described by James Grenning in 2002^[3], is often played with decks that add 0 and ½ at the bottom, round the top to 20, 40 and 100, and include a “?” card. The exact numbers matter much less than everyone on the team using the same ones.

Worked examples

Here is how one fictional team might size four stories, using “add a field to the user profile page” as their 3-point reference. These values are not correct answers — a different team, with a different codebase and different experience, could reasonably land elsewhere.

“Fix the typo in the password-reset email” — 1

One string, one template, nothing to design and almost nothing to test. Clearly smaller than the reference.

“Add a ‘remember me’ checkbox to the login page” — 3

About the size of the reference: a small UI change and a session setting. A team that has never touched its authentication code might argue for 5, because unfamiliarity is uncertainty — and that argument is exactly the kind of thing estimation should surface.

“Let customers export their invoice history as CSV” — 5

A new endpoint, a query, a file format and a button — more moving parts than the reference. If the team has built an export before, it might be a 3; if large accounts could have hundreds of thousands of invoices, performance becomes a real question and it might be an 8.

“Support a second payment provider” — 13 or more

Large, and full of unknowns: the provider’s API, failure handling, reconciliation, testing with real money. A 13 here is really a message — “this is too big to plan as one piece” — and the useful next step is to split it.

Choosing reference stories

• Start with one small, well-understood story the whole team remembers, and agree to call it a 2 or a 3. Leaving room below it means smaller work still has somewhere to go.
• Add one or two larger anchors once you have them — a recent 5 and a recent 8 that everyone agrees felt right in hindsight.
• Write them down where the team estimates, with a line on why each got its number.
• Revisit them occasionally. As the codebase and the team change, an old reference can stop being representative.

What to do with large or uncertain stories

A big number is information, not a plan. When a story comes back as a 13 or 21 — or estimates scatter widely — pick one of these instead of committing to it as-is:

• Clarify. Often the size comes from an open question. Get the answer and estimate again.
• Split. Break it into smaller stories that each deliver something useful, and estimate those.
• Investigate. If nobody knows enough yet, schedule a short, time-boxed spike to find out, and estimate the real work afterwards.
• Estimate with explicit uncertainty. If it has to go ahead, say so: “8, but it could be 13 if the API is as messy as we fear.”

Common mistakes

• Treating points as hours. Once people convert “1 point = 4 hours”, the team is estimating in time again, just in a confusing unit.
• Comparing velocity between teams. Points are calibrated per team. A higher number on another team means nothing about productivity.
• Changing the scale without agreement. Adding a 4, or quietly re-basing the reference story, makes old and new estimates incomparable.
• Averaging disagreements away. A 3 and a 13 averaged to 8 hides the fact that two people understood the story differently. Talk about it instead.
• Using points to judge individuals. Points describe work, not people. Using them as a performance metric is the fastest way to make them meaningless.

Quick reference

Estimating as a team

Story points work best when everyone sizes a story independently first and the team only discusses the stories where estimates differ. That is planning poker, and Async Pointing Poker runs it without a meeting, for teams that track work in JIRA:

• Pick your scale per session. Choose which of ?, 1, 2, 3, 5, 8, 13 and 21 your team uses, and whether people can answer “NA” for work that isn’t theirs to size.
• Estimate by role. Tag each ticket with the roles that should size it — Frontend, Backend, QA, whatever your team uses — and each role gets its own value.
• Estimate independently. Each person sees only their own answer, so nobody anchors on the first number.
• Discuss only the differences. When everyone in a role agrees, the ticket is accepted automatically; disagreements and “?” answers go to the Scrum Master’s review list.

FAQ

Sources

1. ↩Ron Jeffries, “Story Points Revisited” (2019)
2. ↩Mike Cohn, “Why the Fibonacci Sequence Works Well for Estimating”
3. ↩Planning poker (Wikipedia) — origin in James Grenning’s 2002 paper