Fibonacci in Planning Poker: How to Use the Scale
What the gaps between cards mean, why some decks use 20 instead of 21, and how to turn different votes into a useful decision.
Fibonacci Planning Poker uses spaced values such as 1, 2, 3, 5, 8, 13 and 21 to compare the size of work. The cards prompt a choice between meaningfully different estimates. They do not calculate duration or remove uncertainty.
When someone hesitates between 3 and 5, ask what additional work separates the item from a completed reference story. Adding a 4 card gives the team another option, but leaves that question unanswered.
This guide covers:
Why the gaps grow
After 1 and 2, each value in the commonly used sequence is the sum of the previous two: 1, 2, 3, 5, 8, 13, 21, 34…. The absolute gap grows from two points between 3 and 5 to eight between 13 and 21.
That spacing gives the team fewer fine distinctions to defend on larger work. Mike Cohn explains his rationale for Fibonacci and rounded larger values. It is a scale choice, not proof that a particular deck makes estimates accurate.
Suppose a team knows a small settings change well, but a proposed scheduling workflow touches permissions, notifications and concurrent updates. Debating whether the latter is exactly 11 or 12 may suggest more knowledge than the team has. A wider choice can redirect the discussion toward the work behind the number.
The reverse also matters: selecting 13 does not explain a risk. “We do not know whether the calendar provider accepts rescheduling” remains an unanswered question at any point value.
Story points compare work within a team, considering effort, complexity and risk; Atlassian describes this relative estimation approach. An 8 is not a promise of eight hours, and changing the deck does not make two teams' scales comparable.
Fibonacci and modified decks
| Deck | Example numerical cards | What to agree before using it |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21, 34 | Which values your team uses for work it can meaningfully discuss |
| Modified Fibonacci | 1, 2, 3, 5, 8, 13, 20, 40, 100 | What the large values signal and when to return to refinement |
| Additional cards | 0, 0.5, ?, coffee, depending on the deck | What each symbol means for this team |
The modified deck follows Fibonacci through 13, then uses a different progression. 20 is not a missing or incorrect 21. Cohn describes choosing rounded larger values to avoid implying unsupported precision in the estimate.
Likewise, 0.5, question marks and coffee cups are additions to a card deck, not terms in the mathematical sequence. Agree on their meaning. For example, ? can mean “I cannot estimate until we answer this question,” while a coffee card can request a break. Neither is a numerical estimate; keep them separate from point values when recording the outcome.
Choose one deck for the session and keep a few completed reference items beside it. For help choosing references, use Story Points Examples. Avoid changing the scale halfway through a discussion just to obtain a preferred number.
A worked vote: from 3, 5, 8 to a decision
Consider a fictional team building an appointment service. The item says: “Let a customer reschedule an appointment.” The team has an existing appointment page and notification service. Its familiar 3-point reference is a change to one existing booking field, including validation, review and verification.
Three contributors reveal 3, 5 and 8. Here is what they included:
| Vote | Assumption | Question that changes the estimate |
|---|---|---|
| 3 | Update the date field through an existing endpoint | Does saving also reserve the new slot? |
| 5 | Reserve the new slot, release the old one and notify the customer | What happens if another customer takes the slot during the change? |
| 8 | Also synchronize an external calendar and recover from partial failure | Is external-calendar synchronization part of this item? |
The numbers expose three different scopes. Taking their average would hide those differences.
The team clarifies the first slice with the Product Owner:
- Customers can change the time of an appointment before it starts; the booked service stays the same.
- Availability is rechecked when saving; an unavailable slot leaves the existing booking intact.
- The existing notification service sends confirmation after a successful change.
- External-calendar synchronization is excluded and remains a separate backlog item.
The developer familiar with booking storage confirms that its reservation operation already handles conflicts. Everyone can now compare the same bounded change with the reference.
In this illustrative second round, votes are 5, 5 and 5. The team records 5 and the agreed boundaries. This is one possible outcome, not the standard estimate for rescheduling or a requirement that every round end unanimously.
The reveal–discuss–vote-again pattern follows Agile Alliance's description of Planning Poker. For the full meeting sequence, use the step-by-step facilitation guide.
What if the second vote is still 3, 5, 8?
Ask what still differs. If someone cannot confirm safe reservation behavior, write down that question and assign the investigation. If the Product Owner needs calendar synchronization in the same outcome, revisit the scope and possible slices.
Another round is useful when something has changed: a requirement, an assumption or the team's understanding. Repeating the vote without new information can turn estimation into pressure to agree.
When to estimate, split or investigate
Use the explanation behind the card to choose the next action:
| What the discussion reveals | Useful next step |
|---|---|
| Same scope, understood implementation, different comparisons | Revisit completed references, discuss the difference and choose an estimate the team can use |
| Different interpretations of the required behavior | Clarify acceptance boundaries before another vote |
| Several independently useful outcomes in one item | Propose smaller usable slices and estimate them separately |
| An unknown that could change the implementation substantially | Define a bounded investigation with a question, owner and expected evidence |
There is no universal rule that every 13 must be split. Examine whether your team can understand and finish the item within its working constraints. A 5 with a critical unresolved dependency may need clarification sooner than a well-understood 13.
After splitting, the new estimates need not add back up to the old value. You have changed the scope and learned more. Avoid dividing a 13 into “frontend 5” and “backend 8” merely to preserve the total; look for a smaller outcome someone can actually use.
Write a short agreement for your team
Copy this into your team notes before the next estimation session:
Deck and values we use:
Completed reference items and their boundaries:
Work included in each estimate, through our Definition of Done:
Meaning of 0, 0.5 and special cards, if present:
Questions we ask when votes differ:
Signals to clarify, split or investigate:
Where we record assumptions and the next owner:
Keep the agreement practical. “Ask whether data recovery is included” is easier to act on than “consider complexity.” Update references when the team learns that an old example no longer represents its current work.
Questions about the scale
Why is there no 4 card?
The Fibonacci progression moves from 3 to 5. If a task feels between them, compare its boundaries with your references and explain the difference. Teams can use other decks, but adding a value is a working agreement, not a way to settle an unresolved requirement.
Does Scrum require Fibonacci estimates?
No. The Scrum Guide gives sizing responsibility to the Developers and prescribes no Fibonacci sequence, Planning Poker session or story-point scale.
Should we always choose the higher card when uncertain?
Make the uncertainty explicit first. A larger label can reflect work the team understands; it cannot answer a missing product decision or establish whether a dependency works. Agree what evidence is needed before committing to a number.
Try the scale in Agilo
Agilo Planning Poker includes Fibonacci and modified Fibonacci decks. Bring a few bounded backlog items and your reference notes; use the cards to surface assumptions and record the team's decision in your backlog.
Create a Planning Poker room when your team is ready to estimate together.
