Key Takeaways
- Agile teams use Fibonacci numbers (1, 2, 3, 5, 8, 13, 21) because the increasing gaps reflect growing uncertainty in larger items.
- The sequence forces teams to avoid false precision — you can't pick 6 or 7, so you must commit to 5 or 8.
- Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) adds granularity for small items and broader ranges for epics.
- If a story is estimated at 13+ points, it's usually a sign the story should be broken into smaller pieces.
The Fibonacci sequence explained
The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding ones: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89... Named after the Italian mathematician Leonardo of Pisa (known as Fibonacci), the sequence appears throughout nature — in the spiral of a nautilus shell, the branching of trees, and the arrangement of petals on a flower.
In software estimation, agile teams adopted the Fibonacci sequence because its mathematical properties align naturally with how humans perceive effort and complexity. The ratio between consecutive Fibonacci numbers approaches the golden ratio (approximately 1.618), which means each number is roughly 60% larger than the previous one. This increasing gap is the key to its usefulness.
When estimating small tasks, teams can distinguish fine differences — a 1-point task is clearly different from a 2-point task. But for larger work, the ability to discriminate diminishes. Is a task really 15 effort-units versus 16? No one can reliably tell. The Fibonacci sequence removes these meaningless choices. By jumping from 13 to 21, it forces the team to make a clear, consequential decision rather than agonizing over a single digit.
This property makes the Fibonacci sequence a natural fit for relative estimation, where the goal is not precision but honest expression of uncertainty. The scale itself becomes a tool for better conversations and faster consensus.
Why Fibonacci works for estimation
The math behind the sequence maps to how human brains process relative differences.
Natural uncertainty growth
As work items get larger, the range of possible outcomes widens. The Fibonacci gaps grow proportionally, reflecting the fact that a 13-point story has far more unknowns than a 2-point story. The scale itself encodes increasing uncertainty.
Forces simplification
With no option between 8 and 13, the team must make a clear decision rather than splitting hairs. This eliminates debates over meaningless differences and keeps estimation sessions fast and focused on the work rather than the numbers.
Encourages discussion
When one person votes 5 and another votes 13, the gap is too large to ignore. The Fibonacci scale makes disagreements visible, which triggers conversations that surface hidden assumptions, risks, and missing requirements.
Proven by cognitive research
Research in psychophysics shows that humans perceive differences in relative, logarithmic terms — not linear ones. The Fibonacci sequence approximates this natural perception, making it an intuitive fit for relative estimation.
What each Fibonacci value represents
While every team calibrates differently, here is a general guide to how Fibonacci values map to story complexity.
1 - 2 points: Trivial
Well-understood tasks with minimal risk. Examples include fixing a typo, updating a configuration value, or adding a simple validation rule. The team can complete several of these in a single day.
3 - 5 points: Moderate
Standard development tasks with some complexity. Examples include building a new UI component, adding a REST endpoint with validation, or writing integration tests for an existing feature. These are the bread-and-butter stories of most sprints.
8 - 13 points: Large
Complex work with significant uncertainty. Examples include integrating a third-party API, refactoring a core module, or implementing a multi-step workflow. Stories this size often benefit from being split into smaller pieces.
21+ points: Epic / needs splitting
Stories this large are almost certainly too big for a single sprint. They carry high risk and uncertainty. The team should break them into smaller stories before committing to the work. A 21-point story is a signal, not an estimate.
These ranges are starting points, not rules. Your team will develop its own calibration over the first few sprints. What matters is internal consistency — if a login form was 3 points last sprint, a similarly complex form should be 3 points this sprint. The reference stories your team builds up over time become more valuable than any generic guide.
One useful exercise is to create a reference chartwith one completed story for each Fibonacci value. Post it where the team can see it during estimation sessions. When someone asks “is this a 5 or an 8?” the team can point to concrete examples and compare directly.
The modified Fibonacci sequence
Most planning poker tools — including Scrum Poker — use a modified version of the Fibonacci sequence rather than the pure mathematical series. The typical modified sequence is: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.
The modifications serve practical purposes. The 0 represents a story that requires no effort — perhaps it is already done or can be resolved by flipping a configuration flag. The 1/2 captures tasks that are trivial but not zero effort, like fixing a one-line typo. At the high end, the sequence rounds to 20, 40, and 100 instead of 21, 34, and 55 because round numbers are easier to reason about for very large items.
Planning poker also includes special cards. The coffee cup means “I need a break” — a signal that the session has been running too long. The question mark means “I do not have enough information to estimate this story” — a signal that the team needs more refinement or clarification from the product owner before they can assign a value.
These special cards are important because they give the team a structured way to express uncertainty or fatigue. Without them, team members might just pick a random number to avoid slowing down the session, which degrades estimation quality. A question mark vote is more valuable than a random 5.
Some teams further customize the scale. A popular variation drops the 1/2 and adds an infinity symbol for stories that are impossibly large. Others cap the scale at 13 and use anything above as an automatic “split this story” trigger. The key is that the team agrees on the scale before the first session and uses it consistently.
Fibonacci vs other scales
How the Fibonacci sequence compares to alternative estimation scales.
Fibonacci (1, 2, 3, 5, 8, 13, 21)
The default choice for most agile teams. Increasing gaps prevent false precision while still providing enough granularity for sprint planning. Works well with planning poker and velocity tracking.
T-shirt sizes (XS, S, M, L, XL)
Intuitive and low-friction. Great for roadmap-level estimation and new teams. However, T-shirt sizes are harder to sum for velocity calculation and can mask important differences between M-sized items.
Powers of 2 (1, 2, 4, 8, 16, 32)
Clean doubling pattern makes relative comparison simple: each step is exactly twice the previous. Some teams find this easier to reason about. The downside is fewer options in the mid-range where most stories land.
Linear (1, 2, 3, 4, 5, 6, 7...)
Equal gaps between values. Easy to understand but encourages false precision at higher values. Teams waste time debating whether something is a 7 or an 8. Not recommended for relative estimation.
Tips for using Fibonacci in planning poker
Start every session with a reference story. Before estimating new work, remind the team of the baseline. Pull up a completed 3-point story and say “remember, this is what a 3 feels like.” This anchors the session and prevents calibration drift between sprints.
Time-box discussions to two minutes per story. If the team cannot reach consensus after two rounds of voting and discussion, go with the higher estimate and move on. Long debates over a single story are a sign that the story needs more refinement, not more discussion about numbers.
Use the gaps as a feature, not a limitation. When a team member says “I think this is between 5 and 8,” that is the Fibonacci scale working exactly as intended. The right response is “which is it closer to and why?” This forces the estimator to articulate what they know and what they are uncertain about.
Treat 13+ as a splitting trigger. If a story gets estimated at 13 or above, pause and ask whether it can be broken into two or three smaller stories. Large stories carry more risk, take longer to test, and are harder to complete within a single sprint. Splitting them early improves flow and reduces the chance of carry-over.
Do not chase perfect estimates. The purpose of estimation is to enable planning, not to predict the future. A team that estimates quickly and roughly will outperform a team that estimates slowly and precisely, because velocity absorbs the errors over time. Aim for consistency and speed, not accuracy on individual stories.
Review estimates in retrospectives. Once a sprint is complete, briefly compare actual effort to original estimates. Not to punish misses, but to improve calibration. If the team consistently underestimates backend work, that is a useful insight that will improve future sessions.
Frequently asked questions
The Fibonacci sequence has increasing gaps between values, which mirrors real-world estimation uncertainty. As work gets larger, precision decreases — the Fibonacci scale forces teams to acknowledge this by not offering choices between, say, 9 and 10. This prevents false precision and speeds up estimation.
The modified Fibonacci sequence typically includes 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, and 100. It also includes special cards like a coffee cup (need a break) and a question mark (not enough information to estimate). The modifications make the scale more practical for real-world estimation sessions.
A 13-point story is typically a large, complex item with significant uncertainty. Most teams treat anything 13 points or above as a candidate for splitting into smaller stories. The high point value signals that the team should discuss whether the story can be broken down before committing to it.
New teams can start with either. Fibonacci is the most common choice because most planning poker tools default to it. However, T-shirt sizes or a simplified scale (1, 2, 3, 5, 8) can feel less intimidating. The important thing is to pick a scale and use it consistently.
Velocity is the sum of story points completed per sprint. The Fibonacci scale does not change how velocity is calculated — it only affects the values assigned to individual stories. Over time, velocity measured with Fibonacci values stabilizes just as it would with any other relative scale.
Continue reading
More guides on agile estimation and team practices.
What is planning poker?
Learn what planning poker is, how the estimation technique works, and why agile teams use it for sprint planning.
Read guidePlanning poker vs T-shirt sizing
Compare planning poker and T-shirt sizing estimation methods. Learn the pros, cons, and when to use each technique.
Read guideEstimating user stories
A practical guide to estimating user stories using story points. Learn the process, common scales, and mistakes to avoid.
Read guide