Definition
Planning Poker is a consensus-based estimation technique used in agile teams. Each team member privately selects a card representing their effort estimate (typically using the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21), then everyone reveals simultaneously. If estimates diverge significantly. Say one person plays a 3 and another plays a 13. The high and low estimators explain their reasoning, and the team re-estimates.
The simultaneous reveal is the key mechanic. James Grenning, who coined the term in 2002, designed it specifically to counter anchoring bias. The tendency for the first number spoken to pull everyone else's estimate toward it. When a senior engineer says "this looks like a 3" before anyone else speaks, the junior developer who was thinking 8 often stays quiet. Planning Poker eliminates that dynamic entirely.
Why It Matters for Product Managers
PMs rely on estimates to plan sprints, set stakeholder expectations, and make trade-off decisions. If estimates are consistently skewed by whoever speaks first, planning becomes unreliable. Teams at companies like Atlassian and Pivotal have reported that Planning Poker produces estimates within 10-15% of actual effort when practiced consistently over multiple sprints.
The discussion triggered by divergent estimates is often more valuable than the number itself. When a backend engineer plays a 13 and a frontend engineer plays a 3, it usually reveals a hidden complexity. A missing API, a data migration, or an edge case the team had not discussed. These conversations surface risks early, before they become mid-sprint surprises.
Planning Poker also gives quieter team members an equal voice. In verbal estimation, senior engineers dominate. With cards, a junior QA engineer's 13 carries the same weight and triggers the same discussion as anyone else's.
How It Works in Practice
- Present the story. The PM reads the user story and acceptance criteria. The team asks clarifying questions but does not discuss effort yet.
- Private estimation. Each participant selects a card (physical or via tools like Pointing Poker, Parabol, or Jira's built-in estimator). Common scales: Fibonacci (1, 2, 3, 5, 8, 13, 21), modified Fibonacci (0.5, 1, 2, 3, 5, 8, 13, 20, 40), or t-shirt sizes (S, M, L, XL).
- Simultaneous reveal. Everyone flips their cards at the same time.
- Discuss outliers. If all estimates cluster (e.g., three 5s and a 3), take the consensus. If they diverge (a 2 and a 13), the high and low voters explain. Often the high voter sees a technical risk others missed.
- Re-estimate. After discussion, the team votes again. Most stories converge in two rounds. If a third round still diverges, the story probably needs to be broken down.
- Record and move on. Log the agreed estimate in story points and proceed to the next item.
Common Pitfalls
- Letting discussion happen before the reveal. The moment someone says "this seems small," you have introduced anchoring bias. Enforce silence until cards are flipped.
- Spending too long on a single story. If three rounds of voting still produce divergent estimates, the story is too big or too vague. Split it and move on. Debating a 5 vs. an 8 for 20 minutes is almost always wasted time.
- Averaging instead of discussing. "Let us just call it a 5.5" defeats the purpose. The value is in the conversation that divergent estimates trigger, not in the number.
- Skipping it for "obvious" stories. Even simple stories occasionally surface hidden complexity. If the team agrees something is trivial after a quick round, it takes 30 seconds. If it is not trivial, you just avoided a mid-sprint problem.
Related Concepts
- Story Points are the unit of measure most commonly used in Planning Poker sessions.
- Sprint Planning is the ceremony where Planning Poker estimates inform how much work the team commits to for the sprint.
- Agile Estimation covers the broader family of estimation techniques, including t-shirt sizing and ideal days, that teams choose from alongside Planning Poker.