Fibonacci agile estimation
Fibonacci agile estimation uses numbers from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...) to estimate the relative size or effort of work items. Rather than estimating in hours or days, teams assign Fibonacci numbers to represent complexity, uncertainty, and effort. The widening gaps between larger numbers acknowledge that precision decreases as work items get bigger.
Why it matters
Traditional time-based estimation fails in knowledge work for predictable reasons: uncertainty is inherent, scope clarifies during development, and individual productivity varies. Teams that estimate in hours or days find their estimates consistently wrong, leading to missed deadlines and eroded trust.
Fibonacci estimation addresses these problems:
Relative sizing is easier. Humans are better at comparing things than absolute estimation. "Is this bigger than that?" is easier to answer than "How many hours will this take?"
Gaps enforce appropriate precision. You can't estimate something as a 6 because 6 isn't in the sequence. You must choose 5 or 8, acknowledging that fine distinctions don't matter for larger items.
Focus shifts from time to complexity. Points represent effort, complexity, and uncertainty combined. This better reflects what makes work hard.
Velocity provides predictability. Over time, teams establish how many points they complete per sprint. This historical pattern is more reliable than individual estimates.
The fibonacci sequence in estimation
Teams typically use a modified Fibonacci sequence:
1 - Trivial, well-understood work
2 - Small but slightly more involved
3 - Average-sized, clear scope
5 - Moderate complexity or some uncertainty
8 - Significant work, multiple components
13 - Large, should probably be split
21 - Very large, definitely should be split
Some teams include 0 (for trivial changes) and sometimes use other sequences like powers of 2 (1, 2, 4, 8, 16). The principle remains: widening gaps for larger items.
Why fibonacci works
The Fibonacci sequence's properties align well with estimation psychology:
Diminishing precision. The gaps between numbers grow larger (1 to 2 is 1, but 13 to 21 is 8). This reflects reality: the bigger the work, the less meaningful fine distinctions become.
Natural breakpoints. The gaps prevent false precision. You can't say something is a 7; you must choose 5 or 8. This prevents debates about whether something is a 6 or a 7.
Memorable sequence. The pattern is easy to remember and becomes intuitive with practice.
Anchoring support. Teams calibrate by establishing reference items. "A 3 is like when we added the export feature." This creates shared understanding.
Estimation in practice
Fibonacci estimation typically happens during backlog refinement or sprint planning:
Common challenges
Anchoring on time. Teams sometimes mentally convert points to hours. "A 3 is about a day." This undermines the abstraction's value.
Inflation over time. Teams may unconsciously inflate estimates as they become comfortable with the system.
Comparing across teams. Points are team-specific. Team A's 5 isn't equal to Team B's 5. This frustrates organizations wanting portfolio-level views.
Large items going unquestioned. Items estimated at 13 or above often need decomposition, but teams sometimes accept them as is.
Gaming the system. Pressure to hit velocity targets can lead to inflated estimates or gaming behavior.
Making estimation valuable
Estimation serves planning, not accountability:
Tools like Klero can inform estimation by providing historical context on similar feature requests. When teams understand user demand and previous implementation patterns, estimation discussions become more grounded.
