Fibonacci Agile Estimation

Story points are the most argued-over number in agile, and the Fibonacci scale is where most of the arguing happens. Teams adopt it because it matches how people judge size and because it refuses the false precision of a linear scale, then undo it by quietly converting the points back into hours. Understanding why the gaps widen is the difference between a scale that speeds up planning and one that turns into a performance metric, which is why the idea is worth more than the sequence.

What is Fibonacci agile estimation?

Fibonacci agile estimation is the practice of sizing backlog items in story points drawn from the Fibonacci sequence, or more often from a modified version of it, so that the allowed values spread out as they grow: 1, 2, 3, 5, 8, 13, 20, 40, 100. Rather than asking how many hours a story will take, the team asks whether it is about as big as one already sized at a 3 or closer to a 5, and records the answer as a point value.

In the sequence each number is the sum of the two before it, and some teams use the pure form (1, 2, 3, 5, 8, 13, 21, 34) unchanged. The modified scale that rounds the upper values to 20, 40, and 100 was popularized by Mike Cohn's planning poker decks and his 2005 book Agile Estimating and Planning. Story points are the unit; the Fibonacci scale is the set of values the unit is allowed to take. The scale is a vocabulary for relative size, and the specific numbers matter less than the gaps between them.

Why is the scale non-linear?

Because estimates of small things are more reliable than estimates of large things. A team can usually tell a one-point task from a two-point task, since both are small enough to picture in full. It cannot reliably tell a 20 from a 21, because an item that size hides work nobody has looked at yet. Above 13 the next options are 20, 40, and 100, and an argument between 20 and 40 is really about whether the item is understood at all.

The spacing also matches how people perceive difference. Weber's law holds that the smallest noticeable change in a quantity is proportional to the quantity itself, so a step from 2 to 3 feels about as distinct as a step from 8 to 13. The gaps grow with the number so that each step up the scale stays a step the team can actually feel. A 40 or a 100 is less an estimate than a signal that the item should be split before it is planned, a routine outcome of backlog grooming.

What do the points measure?

A story point is a composite of effort, complexity, and uncertainty, attached to a user story or other backlog item and judged relative to others the same team has sized. Effort is the volume of work, complexity is how hard the work is to think through, and uncertainty is how much the team doesn't yet know. A small item with one nasty unknown and a large item of routine work can land on the same number, because the number says how big the commitment feels, not how long it will take.

Points are also local to the team that assigned them. One team's 5 is not another team's 5, because each calibrates against its own reference items, so a point total cannot be compared across teams or used to rate an individual. Velocity, the number of points a team completes per sprint, is the only figure derived from them, and it exists only to help that team plan the next sprint. Story points describe the work from the inside, and the moment they are read from the outside they stop being true.

How does Fibonacci estimation fit the agile ceremonies?

The usual setting is planning poker, first described by James Grenning in 2002 and spread by Cohn's card decks. Each estimator holds cards carrying the scale; a story is read, questions are asked, and everyone reveals a card at once so nobody anchors on the first number spoken. When the cards disagree, the highest and lowest estimators explain their reasoning and the group votes again. The conversation is the product, and the number is the receipt.

Most sizing happens in backlog refinement, ahead of the sprint, so that sprint planning can start from items that already carry a value. A new team calibrates by choosing a few completed items as reference stories and sizing everything else against them. A Fibonacci estimate is a comparison, so it is only as good as the reference items the team keeps in view. The Agile Ceremonies lesson covers where refinement and planning sit in the sprint.

How does Fibonacci estimation differ from time-based estimation?

Hours or days say when something will be done, which is what a stakeholder wants and what a developer can least promise, because the time depends on who does the work and what they find halfway through. A point value says how big the item is relative to others and leaves the conversion to time to velocity, which is measured rather than guessed.

Hours are absolute, so they get compared across people and turned into deadlines; points are relative, so they can't be. Time estimation promises a date, and Fibonacci estimation promises only a ranking, which is a weaker promise that a team can actually keep. The cost is that points are harder to explain outside the team, which is why only the forecast leaves it. The Measuring Agile lesson covers how velocity turns those totals into a forecast.

What does Fibonacci agile estimation look like in practice?

The scale starts from the sequence itself. Each value is the sum of the two before it, so 0 and 1 give 1, 1 and 1 give 2, 1 and 2 give 3, and the run continues 5, 8, 13, with the gap between neighbors widening at every step. Picture a refinement session with three stories on the board. A copy change on a settings screen draws a unanimous 1. A new filter on a list the team has built filters for before draws 3s and one 5; the 5 remembers that the last filter broke pagination, the team talks it through, and settles on 3. "Migrate the search index" draws a 13, a 40, and a shrug, and leaves the session as a spike rather than an estimate. The disagreement is doing the work, and the scale is only there to make disagreement visible.

The sequence behind the scale: every value is the sum of the two before it, which is why the gaps widen as the numbers grow and why teams keep the sequence up to 13 or 20 before switching to rounder values. From the lesson Product Management Terms for Planning & Estimation.

What are the common misuses of Fibonacci estimation?

Converting points to hours is the most damaging. Once a 5 "means" two days, the scale is a time estimate with extra steps, and the uncertainty it was built to express disappears. Comparing velocity across teams is the second: because each team's points are calibrated locally, a team that finishes 60 points is not twice as productive as one that finishes 30. Point inflation follows as soon as velocity becomes a target; items get sized higher, velocity rises, and nothing has changed except the numbers.

Two smaller misuses live inside the ceremony. Averaging the cards instead of talking through the gap skips the conversation that was the point. Treating a 40 or a 100 as a commitment rather than a request to split puts an item into a sprint that was never understood. Every misuse turns a relative, team-internal signal into an absolute, externally reported figure, and the scale does not survive the change. The retrospective is where a team usually notices, and the fix is to re-establish the reference stories and stop publishing velocity outside the team.

What does Fibonacci estimation mean for designers and product managers?

For designers, the scale is a way to size design work on the same ladder as development without pretending it is the same work. Design tasks are often more uncertain than code tasks of similar volume, and a Fibonacci value carries that uncertainty honestly where an hour count would hide it. Design teams that estimate at all tend to live at the small end of the scale and to treat anything above an 8 as a sign that discovery is unfinished.

For product managers, points are an input, never a report. A product roadmap built on velocity holds as a forecast with a margin of error, not as a schedule, and the most useful thing a product manager can do with the scale is defend it: keep points out of status reports, refuse to compare teams, and treat a 40 as a request for a conversation. Fibonacci estimation works for exactly as long as the people outside the team leave the numbers alone.