Planning Poker: Agile Estimation with Fibonacci Cards
Planning Poker is a playful estimation method in agile teams: everyone secretly picks a Fibonacci card and reveals it simultaneously. This produces consensus-based relative effort estimates in story points, free of individual bias.
Planning Poker (also called Scrum Poker) is a consensus-based estimation technique that agile teams use to jointly assess the effort of user stories and backlog items. Instead of naming an absolute duration in hours or days, team members assign relative values - usually story points based on the Fibonacci sequence. The playful card mechanism ensures that each opinion stays unbiased at first and that discrepancies are discussed deliberately.
Origin and Idea
The method became popular in the agile community in the early 2000s and combines two core ideas: relative estimation and collective intelligence. Relative estimation means that tasks are assessed in comparison to one another ("this story is about twice the effort of that one") rather than in absolute time units. Collective intelligence leverages the distributed knowledge of the whole team - development, testing, and domain perspectives all feed into the estimate.
The Fibonacci Sequence as Card Values
The cards typically carry values from the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. The growing gap between the numbers is intentional: the larger and more uncertain a task, the less precise any estimate becomes. The jumps force the team to commit to an order of magnitude instead of arguing over false precision like "6 or 7".
- Fibonacci (1, 2, 3, 5, 8, 13, 21): The classic, naturally reflecting increasing uncertainty.
- Modified Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100): Rounded larger values for better readability.
- Special cards: Often supplemented by "0" (already done), "?" (too little information to estimate), "infinity" (far too large, must be split), and a coffee-cup card for a break.
Flow of an Estimation Round
A typical Planning Poker round follows a clear pattern:
- Presentation: The Product Owner presents a user story and explains its goal and acceptance criteria.
- Clarification: The team asks questions to understand open points and dependencies.
- Hidden choice: Each member independently selects a card representing their estimate - still face down, so no one is influenced.
- Simultaneous reveal: On a signal, everyone reveals their card at the same time.
- Discussion on divergence: If the values differ widely, especially the highest and lowest estimates explain their reasoning. Often someone knows a risk or a simpler path the others did not see.
- Re-estimation: After the discussion the team estimates again, until the values converge or a consensus is reached.
Why Hidden and Simultaneous Reveal?
The heart of the method is the simultaneous reveal. If estimates were spoken one after another, an anchoring effect would emerge: the first number stated influences all that follow, and more senior or louder voices dominate. Through the hidden, simultaneous choice, each person contributes their honest assessment. The divergences in particular are valuable because they surface differing assumptions and build shared understanding.
Relation to Story Points and Velocity
Planning Poker is the tool teams use to assign story points. The estimated points flow into the sprint backlog and, across several sprints, form the velocity - the average number of story points a team completes per sprint. This connection makes Planning Poker a building block of reliable sprint and release planning: the individual estimate is not decisive, but rather the average that stabilizes over time.
Distinction from Absolute Time Estimation
The most important difference from classic time estimates in hours or days:
- Relative instead of absolute: Story points describe size relative to each other, not duration. They are independent of who implements the task.
- Multidimensional: Complexity, uncertainty, and scope all feed into the estimate - not just pure working time.
- Less false precision: The coarse Fibonacci scale prevents the deceptive precision of exact hour figures.
- Team-specific: A story point means something different in each team; comparisons between teams are therefore misleading.
Advantages
- Avoids anchoring and authority effects through the hidden, simultaneous choice.
- Promotes knowledge exchange: discussions on divergence surface risks, assumptions, and simpler solutions.
- Involves the whole team and creates shared understanding of the requirement.
- Fast and low-barrier: the card mechanism is explained in minutes and works both on-site and in remote tools.
- Surfaces misunderstandings early: large divergences signal that the story is not yet well understood or is cut too coarsely.
Limits and Common Mistakes
- Time effort with large backlogs: poking every story individually can be lengthy; faster methods like Team Estimation Game or Affinity Estimation are better suited for bulk estimation.
- Mistaking points for time: if story points are secretly translated back into hours, the benefit of relative estimation is lost.
- Pressure toward consensus: if quick agreement is pushed, quieter members suppress their concerns - and exactly those valuable divergences are lost.
- Missing reference stories: without calibrated comparison stories, values drift apart over time (story point inflation).
- Estimate as commitment: an estimate is a forecast, not a binding promise; treating it as one breeds fear of honest values.
Practical Tips
- Define a few reference stories up front (e.g. "a typical 3, a typical 8") to anchor new estimates.
- Split stories that receive 13 or more points before implementation - they are usually too large for one sprint.
- On a "?" card, clarify the open question first instead of guessing.
- For distributed teams, use digital Planning Poker tools that replicate hidden choice and simultaneous reveal.
- Focus on the discussion, not the number - the real value lies in the shared understanding.
Used well, Planning Poker is less a puzzle about the "correct" number than a structured conversation. It makes differing viewpoints visible, creates a common picture of the task, and produces, as a byproduct, the relative estimates on which reliable agile planning is built.