Fibonacci planning poker is the most widely used agile estimation technique. Understand the sequence, run a live session with your team, and reach consensus faster — no signup required.
Fibonacci planning poker is a consensus-based estimation technique used by agile teams to size user stories and backlog items in relative terms. Team members privately select a card from a Fibonacci-numbered deck, then reveal their choices simultaneously. Disagreements spark focused discussion that surfaces hidden assumptions and risks.
The technique was popularized by Mike Cohn in Agile Estimation and Planning and has since become the default method for Scrum teams worldwide. The Fibonacci sequence is used instead of a linear 1–10 scale because its exponentially growing gaps eliminate false precision and match how humans actually perceive differences in effort and complexity.
The Fibonacci sequence is a series where each number is the sum of the two before it: 0, 1, 1, 2, 3, 5, 8, 13, 21... For agile estimation, it has one crucial property: each step is roughly 60% larger than the previous one.
This matches Weber's Law from cognitive psychology — the principle that humans can reliably distinguish between two quantities only when they differ by at least 50–60%. A linear scale (1, 2, 3, 4, 5) forces teams into meaningless debates over whether a story deserves a 6 or a 7.
A Fibonacci scale (5, 8, 13) makes that distinction obvious: either the story is roughly a 5 or it is genuinely an 8. There is no in-between.
Product Owner, Scrum Master, and development team join the session. In online tools, everyone enters the same room link — no account needed.
The Product Owner reads a story from the backlog. The team asks clarifying questions to surface assumptions, dependencies, and risks before estimating.
Each participant silently selects the Fibonacci number that best represents the relative effort, complexity, and risk of the story. No one reveals their card yet — this prevents anchoring bias.
On the moderator's count, everyone flips their cards at the same time. The spread of estimates is immediately visible to all.
The team member with the highest estimate and the one with the lowest each explain their reasoning. These are the most valuable minutes of the session.
The team votes again, continuing until a clear consensus card emerges. Studies show that most stories reach consensus within two rounds.
| Scale | Values | Best for | Usage |
|---|---|---|---|
| Fibonacci (modified) ✓ | 0,1,2,3,5,8,13,20,40,100 | Cross-functional Scrum teams — recommended for most | ~65% of agile teams |
| Powers of Two | 1,2,4,8,16,32 | Engineering-heavy teams preferring math clarity | ~15% |
| T-Shirt Sizes | XS,S,M,L,XL,XXL | Early roadmap grooming, non-technical stakeholders | ~12% |
| Linear (1–10) | 1,2,3,4,5,6,7,8,9,10 | Not recommended — creates false precision | ~8% |
The consensus among Scrum trainers: start with modified Fibonacci unless your team has a specific reason to deviate.
Fibonacci forces a real choice: is this a 5 or an 8? That 60% gap represents a genuinely different level of complexity — unlike linear scales where 6 vs 7 carries no meaningful difference.
Simultaneous card reveal means no one influences anyone else's estimate. Research consistently shows early numbers skew subsequent estimates regardless of actual complexity.
When one member plays a 3 and another plays a 13, it reveals the team doesn't share the same understanding. That conversation, had now, is cheaper than the surprise mid-sprint.
Teams using consistent Fibonacci story points build reliable velocity data, making sprint planning more accurate with every iteration.
Gaps between Fibonacci numbers grow as numbers get larger, naturally reflecting that bigger stories carry more unknowns. A 100-point story should feel very different from an 8-point story.
When engineers participate in estimation rather than receiving a number from above, they feel ownership over the commitment. Sprint velocity becomes more consistent as a result.
Answer these questions about your current process to see how mature your Fibonacci planning poker sessions are.
Agree on a 1-point (tiny), 5-point (moderate), and 13-point (large) reference story. All future estimates are made relative to these, not abstract hours.
Story points measure relative complexity — not time. Converting 8 points to "roughly 8 hours" destroys the value of relative estimation.
Any story consistently earning votes above 13 is likely too large and too uncertain to deliver in a single sprint. Treat a high estimate as a signal to decompose.
Periodically compare original estimates to actual delivery. Teams that close this feedback loop consistently improve estimation accuracy over time.
Put the theory into practice with your team right now. No credit card, no email, no friction.
Create Free Room →