Fibonacci Sequence in Agile Estimation: Why Those Weird Numbers Work

The Argument Over Whether Something Is a 6 or a 7

Picture this. Your team is estimating a story, and two developers are in a heated discussion about whether the task is a 6 or a 7. They’ve been going back and forth for five minutes. Neither will budge. Meanwhile, the rest of the team has mentally checked out.

Now imagine the same team using the Fibonacci scale. The choice is between 5 and 8. That gap is meaningful. It represents a real difference in effort and uncertainty. The conversation shifts from splitting hairs to asking: “Is this closer to our baseline 5-point story, or does it have enough unknowns to push it to an 8?”

That shift is the entire reason Fibonacci works for estimation. It removes the options that don’t matter and keeps the ones that do.

Why Not Just Use 1 Through 10?

A linear scale from 1 to 10 feels intuitive. But it creates a problem that shows up immediately in estimation sessions: false precision.

On a linear scale, the difference between a 4 and a 5 is the same as the difference between a 9 and a 10. But that’s not how work actually scales. A task that’s twice as big as a small task doesn’t have twice the uncertainty. It has significantly more. The number of unknowns, integration points, and potential surprises increases disproportionately with size.

Linear scales let teams pretend they can distinguish between fine-grained levels of effort on large items. Can you really tell the difference between a 7 and an 8 on a complex feature? Almost certainly not. But teams will argue about it anyway because the scale allows it.

Fibonacci removes that option. After 5, the next choice is 8. After 8, it’s 13. The gaps get bigger because your confidence should get smaller.

The Psychology Behind Relative Sizing

Humans are remarkably bad at estimating absolute values but surprisingly good at comparing things. Research in cognitive psychology consistently shows that people can reliably say “this is bigger than that” long before they can accurately say “this weighs 3.2 kilograms.”

Fibonacci estimation takes advantage of this. When your team looks at a new story, they’re not asking “how many hours will this take?” They’re asking “compared to that 3-point story we did last sprint, is this bigger or smaller? By how much?”

The comparison is natural. The scale provides just enough resolution for small items (where you can differentiate more confidently) and deliberately coarse resolution for large items (where you can’t). That’s not a bug in the system. That’s the system working exactly as intended.

Larger Items = More Uncertainty = Bigger Gaps

Consider this pattern with real work:

• 1 point: Change a button label. You know exactly what needs to happen. Zero uncertainty.
• 2 points: Add a validation rule to an existing form. Slightly more work, but still well-understood.
• 3 points: Build a new API endpoint following an existing pattern. Some work, some decisions, but the path is clear.
• 5 points: Integrate with a third-party service you’ve used before. Known territory, but there are configuration details and edge cases.
• 8 points: Build a new feature that touches multiple services. Some unknowns. You’ll probably discover things during implementation that change your approach.
• 13 points: Redesign a core workflow. Multiple unknowns, cross-team dependencies, and design decisions that haven’t been made yet.
• 21 points: This is a red flag. Something this large has so much uncertainty that any estimate is essentially a guess. Break it down.

Notice how the uncertainty grows faster than the numbers. The difference between 1 and 2 is minor. The difference between 8 and 13 is substantial. Fibonacci captures that reality. A linear scale would treat both gaps as roughly equivalent.

How Fibonacci Prevents False Precision

False precision is when your numbers imply more accuracy than you actually have. If you estimate a complex feature at exactly 7 on a 1-to-10 scale, that number suggests you’ve carefully evaluated the work and landed on a specific level of effort. But for anything beyond simple tasks, that precision is an illusion.

Fibonacci forces honesty. When the options are 5 or 8, your team has to make a real judgement call. There’s no safe middle ground. That constraint produces better conversations because the team has to discuss why they lean one way or the other, rather than silently converging on a comfortable midpoint.

The gaps also serve as natural break points for splitting work. If something feels like it’s solidly between 8 and 13, that’s a signal. The story probably has distinct chunks of work that could be separated into smaller, more estimable pieces.

Modified Fibonacci Scales

The pure Fibonacci sequence goes 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Most Agile teams use a modified version that’s more practical for estimation:

Common modified scale: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

The modifications serve specific purposes:

• 0 points: Already done, or so trivial it’s just a configuration change. Useful for tracking items that need to go through the board but require negligible effort.
• 0.5 points: Slightly more than zero. A quick fix that still needs testing and deployment.
• 20 instead of 21: Some teams round to nicer numbers at the higher end. The precision difference between 20 and 21 is meaningless at that scale.
• 40 and 100: These are “too big to estimate” markers. Anything this large needs to be broken into smaller stories before the team commits to it.

Some teams also use t-shirt sizes (XS, S, M, L, XL) that map to Fibonacci numbers behind the scenes. This can feel less intimidating for teams new to estimation because it removes the urge to do math with the numbers.

Using Fibonacci in Practice: Planning Poker

The most common technique for Fibonacci estimation is Planning Poker. Here’s how it works:

• Each team member has a set of cards with Fibonacci numbers (physical cards or a digital tool).
• The Product Owner describes a user story and answers questions.
• Each person privately selects the card that represents their estimate.
• Everyone reveals their cards simultaneously.
• If estimates differ, the highest and lowest estimators explain their reasoning.
• The team discusses and re-estimates until they converge.

The simultaneous reveal is critical. It prevents anchoring, where the first number spoken influences everyone else’s estimate. Without it, junior developers tend to defer to senior developers, and you lose the diversity of perspectives that makes team estimation valuable.

Keep rounds short. If the team can’t converge after two rounds of discussion, go with the higher estimate and move on. The goal is reasonable estimates, not perfect ones.

When to Skip Fibonacci (and Estimation Entirely)

Fibonacci estimation is a tool, not a requirement. Some situations where you might skip it:

• Mature teams with consistent story sizes: If your team breaks work down so well that everything takes roughly the same effort, just count stories. No estimation needed.
• Kanban teams focused on flow: If you’re optimising for cycle time and throughput rather than sprint capacity, estimation adds overhead without proportional value.
• Support and maintenance work: If most tickets are small fixes with similar scope, the overhead of estimation outweighs the planning benefit.
• When estimation becomes theatre: If the team goes through the motions but nobody uses the estimates for planning, stop estimating. Fix the planning process first.

The question to ask is always: “Does this estimation help us plan better?” If the answer is yes, keep doing it. If the answer is no, spend that time on something more useful.

Frequently Asked Questions

Why does Agile use Fibonacci numbers for estimation?

Fibonacci numbers have increasing gaps between values, which reflects how uncertainty grows with task size. Small tasks can be estimated with reasonable precision, but large tasks carry significantly more unknowns. The growing gaps force teams to acknowledge that uncertainty instead of pretending they can distinguish between, say, a 6 and a 7 on a complex feature.

What Fibonacci numbers are used in Agile estimation?

The most common scale is 1, 2, 3, 5, 8, 13, 21. Some teams add 0 and 0.5 at the low end for trivial tasks, and use 40 or 100 as markers for items that are too large to estimate and need to be broken down. The exact scale matters less than using it consistently.

Is the Fibonacci scale mandatory in Agile?

Not at all. Fibonacci is the most popular choice, but it’s not prescribed by Scrum, Kanban, or any Agile framework. Some teams use powers of 2 (1, 2, 4, 8, 16). Others use t-shirt sizes (S, M, L, XL). Some skip estimation entirely. Use whatever scale helps your team plan effectively.

What do you do when a story is bigger than 13 points?

Break it down. A story estimated at 13 or above usually has multiple distinct pieces of work bundled together. Splitting it into smaller stories gives you better estimates on each piece, reduces risk, and lets you deliver value incrementally. If the team can’t figure out how to split it, that’s often a sign the requirements need more refinement.

What is the difference between Fibonacci and t-shirt sizing?

Both are relative estimation techniques. T-shirt sizes (S, M, L, XL) use labels instead of numbers, which removes the temptation to do arithmetic with the values. Many teams map t-shirt sizes to Fibonacci numbers behind the scenes for velocity tracking. T-shirt sizing works well as a starting point for teams new to relative estimation.

How do you calibrate a Fibonacci scale for your team?

Start with a reference story. Pick a completed story that the whole team agrees was medium effort and call it a 3 or 5. Then estimate new work by comparing it to that reference. Over two to three sprints, your team will build shared understanding of what each number means. Revisit your reference stories periodically to make sure the scale still feels right.

Can you add numbers to the Fibonacci scale?

Some teams add 0 for already-done items, 0.5 for trivial tasks, or round higher numbers (using 20 instead of 21). These modifications are fine as long as the core principle is preserved: gaps between values should grow as the numbers get larger. Adding a 4 or a 6 defeats the purpose because it reintroduces the false precision the scale is designed to prevent.

Why do teams argue during Fibonacci estimation?

Disagreement during estimation is actually the most valuable part of the process. When two people see the same story differently, it usually means they have different assumptions about scope, complexity, or approach. The discussion that follows surfaces those differences early, before anyone starts building. Teams that always agree instantly are probably not thinking critically about the work.