Skip to main content
New: 9 PM Courses with hands-on exercises and certificates
Back to Glossary
DeliveryF

Fibonacci Estimation

Definition

Fibonacci estimation is an agile estimation technique where teams assign story points using numbers from the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. Some teams extend to 34 and use a "?" card for items that cannot be estimated. The sequence is used because the increasing gaps between numbers reflect a fundamental truth about software estimation: the larger the work, the less precisely you can estimate it.

The technique is most commonly used during planning poker sessions, where team members independently select a Fibonacci number for each backlog item and then reveal their estimates simultaneously. Divergent estimates trigger discussion. If one developer estimates a 3 and another estimates a 13, the team discusses their assumptions until they converge.

Fibonacci estimation differs from T-shirt sizing, which uses relative labels (S, M, L, XL) instead of numbers. Fibonacci gives you numerical values that can be summed for velocity tracking and sprint capacity planning. T-shirt sizing is faster but less precise. Many teams start with T-shirt sizing for early-stage roadmap planning and switch to Fibonacci for sprint-level estimation.

Why It Matters for Product Managers

Fibonacci estimation gives PMs the data they need for delivery forecasting. When you know the team's average velocity is 30 story points per sprint and the remaining backlog totals 120 points, you can estimate roughly 4 sprints to completion. This is imprecise, but it is far better than guessing.

The estimation conversations are often more valuable than the numbers themselves. When an engineer estimates a seemingly simple feature at 13 points, the discussion reveals hidden complexity: database migrations, third-party API limitations, edge cases the PM had not considered. These conversations improve the PM's understanding of technical constraints and lead to better-scoped requirements. The RICE calculator can help you weigh the estimated effort against the expected impact when prioritizing items.

How to Apply It

  • Calibrate the team by estimating 3-5 completed items as reference points (anchor stories)
  • Use planning poker to prevent anchoring bias during estimation sessions
  • If an item is estimated at 13+, break it down into smaller pieces before the sprint
  • Track velocity using Fibonacci sums to improve sprint planning accuracy over time
  • Re-estimate items when significant new information emerges (scope change, technical discovery)
  • Never use story points to compare productivity across teams (different teams calibrate differently)

For a structured approach to estimation sessions, see the sprint planning guide. Teams that find Fibonacci estimation too heavyweight for early-stage planning may prefer T-shirt sizing as a lighter alternative.

Frequently Asked Questions

Why use Fibonacci numbers instead of linear numbers for estimation?+
The Fibonacci sequence grows exponentially, which mirrors how estimation uncertainty works. The difference between a 1-point and a 2-point story is small and easy to distinguish. The difference between a 13-point and a 21-point story is large and uncertain. Using linear numbers (1 through 10) implies a false precision. Can you really tell the difference between a 7 and an 8? Probably not. But you can tell the difference between a 5 and an 8. The gaps in the Fibonacci sequence force the team to make meaningful distinctions rather than haggling over one-point differences.
What does each Fibonacci number typically represent?+
While every team calibrates differently, a common baseline is: 1 = trivial change, under an hour. 2 = small, well-understood task, half a day. 3 = moderate task, about a day. 5 = several days of work with some unknowns. 8 = about a week of work, meaningful complexity. 13 = large, complex work with significant unknowns, likely needs decomposition. 21 = too large to estimate accurately, must be broken into smaller items. Most teams agree that anything above 8 should be split. Some teams add 0.5 for typo-level fixes and use infinity for items that are not yet understood enough to estimate.
Should product managers care about story point estimation?+
PMs should care about the outcomes of estimation (can we predict when things ship?) without micromanaging the process. Story points belong to the engineering team. The PM's role in estimation is to provide context: what is the expected behavior, what edge cases matter, what level of quality is needed. If engineers estimate something at 13 points and the PM expected it to be a 3, that is a valuable conversation about hidden complexity or misaligned expectations. Use the estimates to inform your roadmap and delivery forecasts, not to pressure the team into lower numbers.

Explore More PM Terms

Browse our complete glossary of 100+ product management terms.