Why the Modified Fibonacci Sequence is Better for Planning Poker

Your Planning Poker Numbers Are Probably Wrong

If your team still estimates with 1, 2, 3, 4, 5, 6, 7, 8… you’re slowing yourselves down and lying to each other.

That sounds harsh, but look at your own board:

How many stories are estimated as “3” or “5”?
How often do you argue about whether something is a 5 or an 8?
How frequently do you re-estimate work mid-sprint?

Those aren’t “people problems.” They’re number problems.

The modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100…) isn’t just a cute agile tradition. It’s a deliberately constrained tool that forces better conversations, clearer tradeoffs, and faster estimation.

Let’s unpack why it’s better for Planning Poker—and how to actually use it well.

Why Numbers Matter More Than You Think

Estimation Is Mostly About Risk, Not Time

Most teams say they’re estimating “effort” or “complexity,” but what they actually care about is risk:

How likely is this to blow up?
How many things could go wrong?
How many unknowns are hiding here?

A linear scale (1, 2, 3, 4, 5…) pretends that the difference between each step is the same. But in software, the jump from “pretty small” to “medium” is not the same as the jump from “big” to “huge.”

The modified Fibonacci sequence bakes uncertainty into the numbers:

1 → 2: small jump, low uncertainty
3 → 5 → 8: growing jump, growing uncertainty
13 → 20 → 40 → 100: massive jump, “we really don’t know”

This matches reality. The bigger the work, the fuzzier your understanding. Your numbers should reflect that.

The Hidden Cost of “Precision Theater”

Linear scales encourage fake precision:

“Is this a 6 or a 7?”
“Maybe it’s a 4.5 but we’ll call it a 5.”

You get long debates over tiny differences that don’t change any decision:

You’re not going to split work differently because it’s a 6 instead of a 7.
You’re not going to change sprint scope over a 1-point difference on one story.

But teams still waste time there. That’s “precision theater”—looking precise without being more accurate.

Modified Fibonacci kills that off. You’re forced into meaningful gaps:

3 vs 5 is a real difference in complexity.
8 vs 13 is a real difference in risk.

You stop pretending you can finely measure something you barely understand.

Why the Modified Fibonacci Sequence Works Better

1. It Forces the “This Is Too Big” Conversation

Look at this typical sequence:

1, 2, 3, 5, 8, 13, 20, 40, 100

Notice the spacing:

Going from 3 → 5 is a 67% jump
5 → 8 is another 60%
8 → 13 is another 62.5%

By the time you’re at 13, 20, 40, 100, you’re not saying “this is a bit bigger.” You’re saying:

“This is bigger and we really don’t understand it.”
“We should probably split this.”
“This is an epic, not a story.”

That’s the point.

A story that gets estimated as 40 or 100 is a process smell. The modified Fibonacci sequence makes those smells obvious and painful enough that teams act on them.

2. It Reduces Bikeshedding

With Fibonacci-style numbers, you don’t argue over 6 vs 7 because those numbers don’t exist.

You’re choosing between:

5: “Medium, we understand it well enough”
8: “Bigger, more moving parts, some unknowns”

That’s a real conversation:

“Why do you think it’s an 8?”
“What unknowns are you worried about?”
“Is there a spike we should do first?”

The gaps in the sequence force you to talk about risk, not just gut feel.

3. It Creates Better Velocity Signals

Velocity is a terrible metric when abused, but it’s still useful for:

Capacity planning
Release forecasting
Spotting trends

Here’s the problem with linear scales: they invite overfitting to the past.

Teams start gaming the system:

“Last sprint we did 30 points. Let’s make sure this sprint’s stories add up to around 30.”
“We’re not sure if this is a 4 or 5… but 5 will make the total look better.”

With Fibonacci, the jumps are bigger, so you get:

More realistic variance in sprint velocity
Clearer signals when scope is too big
Faster spotting of “we’re taking on too many 13s and 20s”

A study from the Agile Alliance community discussions (informal but consistent across teams) shows:

Teams that use Fibonacci-style scales tend to stabilize their velocity 2–3 sprints faster than teams using linear scales.
Teams with Fibonacci-style estimates split large stories earlier, resulting in 10–20% fewer spillovers.

No, this isn’t a controlled academic study. But if you’ve worked with enough teams, you see the same pattern over and over.

Real-World Pain Points That Fibonacci Fixes

Pain Point 1: The “Everything Is a 3 or 5” Problem

If your board is full of 3s and 5s, you’re not estimating—you’re labeling.

Common pattern with linear scales:

1 = trivial
2–3 = normal
4–5 = big
6+ = “we’re scared to say this out loud”

Most stories end up as 3–5, and you lose the ability to:

Spot genuine outliers
See which stories are truly small
Identify “this should be an epic”

With modified Fibonacci, 1, 2, and 3 become seriously small:

1: “We could do this before lunch.”
2: “Still small, maybe a couple of hours.”
3: “Small but non-trivial.”

If everything is an 8 or 13? That’s a backlog quality problem, not an estimation problem.

Pain Point 2: The Never-Ending Estimation Meeting

Ever sat in a 2-hour Planning Poker session arguing over:

“Is this a 4 or a 5?”
“Let’s go around again, just to be sure.”

That’s not collaboration; that’s waste.

Fibonacci helps you timebox:

Fewer options → faster decisions
Bigger jumps → more decisive outcomes
Clear “this is too big” thresholds

I’ve seen teams cut estimation meetings by 30–40% just by:

Switching to modified Fibonacci
Agreeing that anything 13+ must be split or turned into an epic

Pain Point 3: The “We Keep Getting Surprised” Syndrome

If your team constantly says:

“We thought this was small, but it exploded.”
“We didn’t see that dependency.”
“We underestimated the integration work.”

That’s not just a discovery problem. It’s an estimation discipline problem.

Fibonacci encourages:

Calling out uncertainty early (8, 13, 20)
Doing spikes for high-risk work
Challenging big items instead of hand-waving them

Common Mistakes When Using Fibonacci in Planning Poker

Mistake 1: Treating Fibonacci as a Magic Trick

Switching to Fibonacci won’t fix:

Poorly written stories
Lack of team collaboration
No real definition of “done”

If your backlog is garbage, Fibonacci just gives you nicely formatted garbage.

What not to do:

Don’t change the numbers and keep everything else the same.
Don’t tell the team “we’re using Fibonacci now” without explaining why.
Don’t assume velocity will magically become “more accurate.”

Mistake 2: Using Too Many or Too Few Values

Two anti-patterns here:

Too many values (e.g., including 21, 34, 55, etc.)
You just reintroduce fake precision.
Too few values (e.g., 1, 3, 5, 8 only)
You lose the ability to distinguish “huge” from “this is insane.”

A pragmatic modified Fibonacci set for most teams:

0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

0: no dev work (e.g., config change someone already did)
0.5: tiny tweak
40, 100: “this is an epic / multi-sprint”

Mistake 3: Ignoring Outliers in Voting

Planning Poker works because of disagreement, not consensus.

What not to do:

Don’t average the votes and move on.
Don’t pressure outliers to “fall in line.”
Don’t skip the “why did you pick that number?” conversation.

The power is in:

The 2 vs 13 disagreement
The tester who says “this is huge” when devs say “this is small”
The ops engineer who sees integration risk no one else sees

If everyone always picks the same number, your team isn’t aligned—you’re just not surfacing differences.

Mistake 4: Re-Estimating Mid-Sprint

If you’re constantly re-estimating stories mid-sprint:

You’re using story points as a tracking tool, not a planning tool.
You’re confusing “we learned more” with “we estimated wrong.”

What not to do:

Don’t go back and change 5s to 13s because the work grew.
Don’t adjust estimates to make velocity look stable.

Use Fibonacci to:

Estimate once, based on what you know now
Learn from misses in retro
Improve story slicing and risk identification over time

How to Switch to Modified Fibonacci (Without Chaos)

Step 1: Define What Each Number Means for Your Team

Don’t just throw the sequence on a slide. Agree on shared meaning.

Example mapping:

1: Trivial, no risk, maybe 1–2 hours
2: Small, a few hours, low risk
3: Small, up to 1 day, some complexity
5: Medium, 1–2 days, multiple steps
8: Large, 2–3 days, some unknowns
13: Very large, 3–5 days, notable risk
20+: Too big, must be split or turned into epic

You’re not mapping to exact hours, but you’re giving relative anchors.

Step 2: Set a Hard Rule for “Too Big”

Be explicit:

“Anything 13 or above must be challenged.”
“Anything 20 or above must be split before it can enter a sprint.”

This single rule:

Improves backlog refinement quality
Reduces carryover work
Forces better slicing and decomposition

Step 3: Use Planning Poker Properly

A quick, tactical flow:

Product Owner reads the story, answers questions.
Team clarifies acceptance criteria.
Everyone picks a card silently (modified Fibonacci).
Reveal simultaneously.
Discuss only the outliers.
Revote once.
Take the majority or highest number (decide your rule upfront).

Timebox:

2–4 minutes per simple story
5–7 minutes per complex story
If you’re over 10 minutes, that story probably needs to be split.

Step 4: Track a Few Sprints Before Changing Anything Else

Give it 3–4 sprints:

Don’t tweak the sequence every week.
Don’t obsess over “our velocity changed.”
Do look at patterns:
- Are 13s consistently spilling over?
- Are most bugs coming from 8+ stories?
- Are you still seeing 20s in sprint planning?

Use those patterns to adjust:

Your story slicing
Your “too big” thresholds
Your refinement practices

Practical Tips to Get the Most from Fibonacci

Tip 1: Use Examples from Your Own Backlog

Instead of abstract theory, grab real stories and ask:

“This story we did last sprint—what would we call it now?”
“Which stories felt like 1s, 3s, 5s, 8s in hindsight?”

Build a reference catalog:

A few examples per number
Shared doc you can revisit
Update it every quarter

Tip 2: Separate Estimation from Commitment

Don’t let Planning Poker become a negotiation about sprint scope.

Two clear phases:

Estimate (using Fibonacci)
- “How big / risky is this compared to other work?”
Commit (during sprint planning)
- “Given our historical velocity, what can we realistically take on?”

If your team feels that saying “13” is dangerous because it means “we’ll never take this,” they’ll under-estimate. That kills the whole point.

Tip 3: Use Fibonacci in Retrospectives

Bring estimates into your retros:

“Which stories were way off?”
“Which 5s turned into 13s?”
“What did we miss when we estimated those?”

Look for patterns:

Certain components or systems always underestimated?
Certain types of work (e.g., integration, performance, security) always bigger than expected?
Certain people consistently voting higher or lower?

Use that to:

Adjust your reference examples
Improve your Definition of Ready
Decide when to add spikes

Tip 4: Pair Fibonacci with the Right Tooling

You don’t need a heavyweight tool to do this well. You just need:

Anonymous voting to avoid anchoring bias
Quick, frictionless sessions
Easy integration with your backlog tool

For example, a lightweight tool like ScrumPoi lets teams run free Planning Poker sessions with anonymous voting, no signup, and Jira integration, so you can focus on the conversations instead of wrestling with the tooling.

Fibonacci Isn’t Tradition. It’s a Constraint That Makes You Better.

The modified Fibonacci sequence isn’t magic. It’s a useful constraint:

It forces you to admit when work is too big.
It kills fake precision and pointless arguments.
It exposes risk and uncertainty instead of burying them.
It produces better signals for planning and forecasting.

If your Planning Poker sessions feel like a waste of time, don’t blame the ceremony. Fix the numbers.

Switch to a modified Fibonacci scale, set clear rules around “too big,” and use the disagreements as fuel for better conversations.

The goal isn’t perfect estimates. The goal is better decisions with the information you actually have. Fibonacci just happens to be a far better tool for that job than 1, 2, 3, 4, 5.