Every planning poker deck ships with the same sequence: 1, 2, 3, 5, 8, 13, 21. Ask why and you’ll hear the official answer: “Fibonacci reflects growing uncertainty. Larger numbers are fuzzier, so the gaps between them should be too. It prevents false precision.”
That’s true. It’s also solving the wrong problem.
What Fibonacci actually fixes
The case for Fibonacci is real. If you’re estimating in integers — 1 through 10 — teams waste time arguing the difference between a 6 and a 7. Those aren’t meaningfully different estimates. The precision implies information you don’t have.
Fibonacci eliminates the middle choices. There’s no 6. You have to pick 5 or 8, and the jump between them is large enough that the choice reflects an actual difference in how you’re thinking about the ticket.
For a single-number scale, this is a genuine improvement. The sequence makes you commit to a position instead of splitting the difference.
What it doesn’t fix
Here’s what the cards reveal in your next planning session: someone votes 3, someone votes 8, someone votes 13. Discussion begins. Twenty minutes later, the room settles on 8 and moves on.
Fibonacci didn’t prevent that spread. It couldn’t — because the spread usually isn’t caused by people choosing between adjacent numbers. It’s caused by people answering different questions.
The developer who voted 3 was thinking about effort. She’s done this change before. It’s a few hours of clean work on a well-understood part of the system.
The developer who voted 13 was thinking about risk. That service has four downstream dependencies. The last time someone touched it without flagging the integration points, the incident took two days to untangle.
Neither of them is wrong. And the Fibonacci scale has no mechanism to surface that. The gap between 8 and 13 doesn’t help — the problem is that both votes were answers to a question that wasn’t asked.
The scale is not the constraint
The real constraint in single-number estimation is that one number can’t carry four independent dimensions.
Effort — how much engineering work this actually is.
Risk — what external forces could derail it. Dependencies, shared systems, proximity to sensitive infrastructure.
Complexity — how hard the code is to understand and change safely. A ticket in a brittle part of the codebase is complex even when the required change is small.
Uncertainty — how much you don’t know yet. Unclear requirements, unfamiliar territory, a definition of done that keeps shifting.
A ticket can be low effort and high risk. High complexity and low uncertainty. High uncertainty and everything else manageable. These don’t compress cleanly into a single scale — and it doesn’t matter whether that scale runs 1–10 or follows Fibonacci or uses t-shirts. The compression loses information regardless.
What the 13-versus-3 conversation is worth
When your team votes 3 and 13 on the same ticket, you have something valuable in the room: two people who have looked at the same work and noticed different things. That’s the estimation process working.
The standard response is to surface it and negotiate — “why did you vote 13?” — and usually the high voter explains, and the room either updates or caves. What you rarely get out of that conversation is clarity on which dimension drove the outlier vote.
If you split the question — effort first, then risk, then complexity, then uncertainty — that same conversation changes. “I voted effort as low, but risk as high, because this touches the payment service” is a sentence the team can act on. They can flag it before the sprint, assign it to the right person, budget time for testing. “I think it’s a 13” is a position you can only argue with.
The final point estimate becomes an aggregation of four honest assessments rather than a social negotiation over one vague one. You still get a number. You also get the reason behind it.
Fibonacci is a good fix for a real problem. It’s just not the problem that breaks planning sessions.
If you want to try multi-dimensional estimation with your team — Estimate Well runs structured sessions where the team votes separately on effort, risk, complexity, and uncertainty before arriving at a final number. Free, no account needed. Share a link and you’re in.