What Is Planning Poker? How to Estimate Work With Your Agile Team
Planning poker is a collaborative estimation technique used by agile development teams to estimate the effort, complexity, or size of backlog items using a structured, consensus-building process. Each team member independently selects a card representing their estimate — typically using Fibonacci values (1, 2, 3, 5, 8, 13, 21) or similar scales — and all estimates are revealed simultaneously. When estimates diverge, the team discusses the reasons and re-estimates until consensus is reached.
The technique was introduced by James Grenning in 2002 and popularized by Mike Cohn in Agile Estimating and Planning. It addresses several well-known limitations of group estimation, including anchoring bias, groupthink, and the tendency for junior team members to defer to senior opinions.
How Planning Poker Works
The Setup
Each team member has a set of cards with Fibonacci values (or similar): 0, 1, 2, 3, 5, 8, 13, 21, 40, 100, and often special cards for “infinity” (too large to estimate meaningfully) and “?” (don’t understand the story well enough to estimate).
The Process
-
The product owner presents a backlog item — reading the user story aloud, providing context, and answering questions about scope and acceptance criteria.
-
Discussion — Team members ask clarifying questions and the product owner answers. The goal is shared understanding of what’s being estimated, not agreement on the answer.
-
Private selection — Each team member privately selects a card representing their estimate. No one reveals their card yet.
-
Simultaneous reveal — All cards are revealed at the same time. This prevents anchoring — where early estimates influence subsequent ones.
-
Discussion of outliers — When estimates vary significantly (e.g., someone estimates 3 and someone estimates 13), the highest and lowest estimators explain their reasoning. This discussion often reveals different assumptions about scope, complexity, or technical approach.
-
Re-estimate — After discussion, the team estimates again. This cycle repeats until estimates converge or the team decides on a specific value.
Why Simultaneous Reveal Matters
The simultaneous reveal is the most important element of planning poker. When estimates are shared one at a time, each subsequent estimator is influenced by what they’ve already heard. The first person to speak anchors the group’s thinking, and later estimates cluster around that anchor even when they reflect different information.
Simultaneous reveal forces everyone to commit to an estimate before seeing others’ answers — producing estimates that reflect genuine individual judgment rather than social conformity.
What Diverging Estimates Reveal
When planning poker produces diverging estimates, it’s almost never random. The divergence typically reflects:
- Different scope assumptions: One developer interpreted the story broadly; another interpreted it narrowly
- Different technical approaches: Developers have different ideas about how to implement the feature
- Different knowledge of codebase areas: Someone who has worked in the relevant area has more accurate complexity intuition
- Hidden dependencies: One team member knows about a technical dependency the others weren’t aware of
The discussion triggered by diverging estimates is often more valuable than the estimate itself. It surfaces these differences in understanding before development begins — when they’re cheap to resolve — rather than during development, when they’re expensive.
Planning Poker Best Practices
Don’t rush: The goal is accurate estimates through shared understanding, not fast estimates through forced consensus. Take the time for thorough discussion.
Focus on relative size: Story points measure relative complexity, not hours. Keep discussions focused on “how complex is this compared to other stories we’ve done?” rather than “how many hours will this take?”
Split stories that generate persistent disagreement: When a story consistently produces estimates that diverge widely, it’s often too large or too ambiguous to estimate reliably. Split it.
Keep the product owner involved: The product owner should be present to answer scope questions and clarify acceptance criteria, not to influence estimates.
Key Takeaways
Planning poker combines the accuracy of individual expert judgment with the calibration that comes from group discussion, while specifically designing out the social biases that corrupt group estimates. Teams that use it consistently develop better-calibrated estimation intuition, surface design and scope assumptions early, and produce sprint plans that more reliably reflect actual capacity.