What Is Planning Poker? A Guide to Agile Estimation
What Is Planning Poker?
Planning poker is a consensus-based estimation technique used by agile teams to size user stories. Every team member simultaneously reveals a card, preventing any single person's opinion from anchoring the group.
The technique was introduced by James Grenning in 2002 and popularized by Mike Cohn in "Agile Estimating and Planning."
Why "Poker"?
In typical meetings, the first person to speak—or the most senior—tends to anchor the group's opinion. Planning poker eliminates this cognitive bias by having everyone commit to a number before anyone reveals theirs.
Basic Rules
Card Values
Planning poker uses a modified Fibonacci sequence.
| Card | Meaning |
|---|---|
| 0 | No work needed (already done, etc.) |
| 1 | Trivial effort |
| 2 | Small effort |
| 3 | Slightly small effort |
| 5 | Medium effort |
| 8 | Somewhat large effort |
| 13 | Large effort (consider splitting) |
| 21 | Very large effort (must split) |
| ? | Can't estimate (insufficient information) |
| ☕ | Need a break |
The widening gaps reflect the reality that precision decreases as tasks grow larger. Debating "13 or 14" wastes time; "13 or 21" is the right granularity.
Participant Roles
| Role | Participation | Responsibility |
|---|---|---|
| Product Owner (PO) | Explains the story | Provide context and acceptance criteria |
| Scrum Master (SM) | Facilitator | Manage discussion flow and time |
| Development Team | Play cards | Estimate and explain reasoning |
| Stakeholders | Observer | Answer questions (do not play cards) |
Only the development team plays cards. When POs or managers participate in estimation, implicit pressure distorts the results.
Step-by-Step Process
Step 1: Story Presentation (2–3 minutes)
The product owner reads the user story and explains the context and acceptance criteria.
User Story:
"As a user, I want to download my order history as CSV
so I can import it into my budgeting app."
Acceptance Criteria:
- Covers orders from the past 12 months
- CSV includes date, product name, amount, and status
- Download button placed on the order history page
Step 2: Questions and Discussion (3–5 minutes)
The team asks clarifying questions. The goal is to resolve ambiguity, not to design the solution.
Typical questions:
- "Are there performance requirements if the user has 10,000+ orders?"
- "Is UTF-8 the required CSV encoding?"
- "Do we need filters (date range, etc.)?"
Step 3: Simultaneous Card Reveal
After questions, each member selects a card. On the facilitator's signal, everyone reveals simultaneously.
Alice: 5
Bob: 5
Carol: 8
Dave: 13
Step 4: Discuss Divergence (2–5 minutes)
When cards differ significantly (typically a gap of two or more levels), the highest and lowest explain their reasoning.
Dave (13): "Generating CSV for large datasets needs async processing.
We'd need to implement a job queue."
Alice (5): "We can reuse the existing report module's CSV generator.
New code would be minimal."
This discussion surfaces assumptions and blind spots the team hadn't considered.
Step 5: Re-vote and Converge
After discussion, the team votes again. If consensus still isn't reached:
- Take the higher value: When in doubt, round up
- Split the story: Lack of consensus often signals a story that's too large
- Create a spike: For high technical uncertainty, time-box an investigation
Running Planning Poker Online
Remote teams rely on digital tools for planning poker sessions.
Benefits of Online Tools
- Guaranteed simultaneous reveal (no peeking)
- Automatic result recording and statistics
- Built-in timers for time management
- Support for asynchronous estimation
Online-Specific Tips
Remote communication carries less information than face-to-face. Compensate by:
- Turning cameras on: Facial expressions enrich discussion
- Using chat alongside voice: Supplement verbal discussion with written notes
- Enforcing time boxes strictly: Online meetings tend to drag
- Active facilitation: Consciously balance speaking time across the team
Tips for Effective Discussions
Set a Time Box
Limit each story to 5 minutes maximum. If the team can't converge in 5 minutes, the story itself likely needs refinement.
Use the "?" Card
If information is insufficient, play "?" instead of guessing a number. When a "?" appears, identify what's missing and either resolve it on the spot or log it for follow-up.
Always Refer to the Reference Story
When discussion drifts, bring it back to the baseline.
"Compared to our reference story (adding a phone number field = 3 points),
how does this story measure up?"
Draw Out Every Voice
The facilitator should actively invite quieter members to share their perspective. New team members often spot assumptions the rest of the team takes for granted.
Common Challenges and Solutions
Challenge 1: Sessions Take Too Long
Symptom: 10 stories take 2 hours.
Solutions:
- Set a per-story time limit (5 minutes)
- Share stories in advance and collect questions beforehand
- Batch small stories (obviously 1–2 points) for quick consensus
- Cap sessions at 90 minutes
Challenge 2: The Same People Always Give the Highest/Lowest Estimates
Symptom: Cautious Alice always goes high; optimistic Bob always goes low.
Solutions:
- Review past estimates vs. actuals to see whose instincts are closest
- After each estimate, confirm what's included and excluded
- Consistently anchor to the reference story
Challenge 3: The PO Pressures the Estimates
Symptom: "That's 5 points? Can't it be done in 3?"
Solutions:
- Clarify that the PO's role is to explain stories and answer questions, not to set estimates
- If an estimate feels high, adjust scope (reduce acceptance criteria) rather than override the estimate
- Reinforce that estimates are the team's professional judgment
Connecting to Retrospectives
Sprint retrospectives are the ideal time to review estimation accuracy.
What to Review
- Compare completed stories' estimates to their actual complexity
- Analyze stories that were significantly over- or under-estimated
- Check whether estimation assumptions held true
- Share learnings for the next estimation session
Critically, never use retrospectives to blame individuals for estimation misses. Estimates are forecasts—being wrong is natural. The goal is team learning, not accountability.
Summary
Planning poker harnesses the independent judgment of every team member to produce reliable, bias-free estimates. Simultaneous card reveals eliminate anchoring, and the follow-up discussion between high and low estimators deepens the team's understanding of each story. Combined with time-boxed sessions, a reference story baseline, and retrospective reviews, planning poker steadily improves a team's estimation confidence and accuracy.