Planning Poker
A consensus-based estimation technique where team members independently select story point estimates using cards, then discuss differences to reach aligned understanding.
What it is
Planning Poker was created by James Grenning in 2002 and popularised by Mike Cohn through his book Agile Estimating and Planning. It is a structured, game-like approach to estimation that forces independent thinking before group discussion, preventing the anchoring bias that occurs when the first voice in the room sets the tone.
The process follows a simple rhythm for each backlog item:
- The Cards: Each team member receives a deck of cards showing values from the Fibonacci sequence (or a modified scale). Some teams use physical cards; others use digital tools.
- Product Owner reads the description: The PO presents the user story and acceptance criteria. They do not provide estimates or suggest sizes.
- Team asks questions: Developers and testers clarify scope, dependencies, and acceptance criteria. The PO answers or agrees to investigate.
- Private selection: Each participant selects a card that represents their estimate — privately, without showing anyone.
- Simultaneous reveal: On a signal from the facilitator, everyone turns over their card at the same time.
- Discuss outliers: The highest and lowest estimators explain their reasoning. This is where hidden assumptions, risks, or misunderstandings surface.
- Re-estimate: The team repeats the selection and reveal until consensus is reached or the facilitator calls the vote.
When to use it
Planning Poker is used during backlog refinement and sprint planning whenever the team needs to estimate user stories, epics, or features. It is most effective when:
- The team is estimating work for the first time or revisiting an item after new information.
- Multiple perspectives are needed to surface hidden complexity.
- The team wants to calibrate understanding of a story before committing it to a sprint.
- There is uncertainty or disagreement about scope that needs structured discussion.
Key concepts
The Cards
Standard decks use the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, and sometimes a question mark ("I don't know") and an infinity card ("too large to estimate"). Some teams use a modified sequence that replaces 21 with 20 and 13 with 15 for easier mental math. The cards represent story points, not hours or days.
Simultaneous Reveal
The core mechanic of Planning Poker. All cards are shown at once, preventing anchoring and revealing the full range of team opinion in a single moment. If estimates cluster closely, discussion is brief. If they diverge widely, there is a signal that the story is poorly understood or highly uncertain.
The Discussion
After reveal, the outliers speak first. The person with the highest estimate explains what they see that others may have missed. The person with the lowest estimate explains what makes the story simpler than it appears. This cross-pollination of perspective is where the real value of Planning Poker lies — not in the number, but in the shared understanding.
Consensus vs Average
Planning Poker aims for consensus — a number the whole team can live with — not a mathematical average. If the estimates are 3, 3, 5, 5, and 8, taking the average (4.8) defeats the purpose. Instead, the team discusses, re-estimates, and converges. If they land on 5, that reflects a shared understanding, not a compromise.
| Card | When to play it |
|---|---|
| 0 | The story is already done or requires negligible effort |
| 1 | Trivial change; clear path; minimal risk |
| 3 | Standard story; moderate complexity but well understood |
| 5 | Complex story; multiple areas touched; some uncertainty |
| 8 | Large story; significant unknowns; consider splitting |
| 13 | Very large; should be broken down before sprinting |
| 21 | Epic-level; too large to estimate accurately; decompose |
| ? | Not enough information to estimate; needs a spike or clarification |
| ∞ | The story is too large to fit in a sprint; must be split |
Common pitfalls
- Senior revealing first: Even without a formal reveal order, if the senior developer places their card down half a second early, the room anchors. Use a strict countdown or digital tool to enforce simultaneity.
- Spending too long on low-priority items: If a story is not in the next two sprints, a rough estimate is enough. Deep debate on backlog items that may change or be deprioritised is waste.
- Treating it as competitive: The lowest estimate is not "winning" and the highest is not "losing." Framing it as a game with winners creates social pressure to shrink estimates.
- Skipping discussion when estimates are close: A 3-3-3-5 spread may seem close enough to call a 3, but that lone 5 may represent a risk the others missed. Always ask the outlier to speak.
- Authority overriding judgment: When a tech lead or manager plays a 3 and a junior plays an 8, the junior often folds. Facilitators must actively create psychological safety for dissenting estimates.
NZ context
In New Zealand, where many agile teams are distributed across Auckland, Wellington, and Christchurch (or working with overseas counterparts), physical card decks are often impractical. NZ teams commonly use digital tools for remote Planning Poker sessions.
Popular tools include PlanningPoker.com (free, browser-based), Jira plugins such as Story Points Poker or Agile Poker for Jira (integrated with backlog workflow), and Miro boards with card widgets for teams already using Miro for collaboration. For teams in government or enterprise environments with strict procurement, built-in Jira plugins are often preferred for audit trails.
NZ's small team sizes (often 4–7 developers) mean Planning Poker can move quickly, but it also means a single absent member skews the estimate. Teams should defer estimation for stories where a key domain expert is unavailable, rather than guessing without them.
Career level guidance
Junior
- Play the card that honestly reflects your understanding, even if it differs from seniors. Your fresh perspective often catches assumptions others have internalised.
- When you are the outlier, explain your reasoning briefly. "I picked 8 because I'm not familiar with the payment API" is valuable information.
- Listen to why others estimate differently. This is how you build intuition for the team's baseline and your own growth.
- Don't change your card just because someone senior played a different number. The facilitator should ask for your reasoning first.
Senior
- Model intellectual humility. If you played a low number and missed a dependency, say so openly. This sets the tone for honest estimation.
- Watch for juniors folding to your estimate. If you reveal and the room immediately shifts, ask: "Does anyone want to stick with their original number?"
- Help the team know when to stop debating. If estimates have converged to adjacent numbers, suggest taking the higher and moving on.
- Flag when a story should be split or spiked rather than re-estimated endlessly. "We've had three rounds and we're still at 5–13. Let's spike the unknown and estimate later."
Test Lead
- Ensure testing effort is visible in the estimate, not treated as an implicit overhead. A story with heavy regression or automation work should reflect that in its points.
- Watch for stories where testing is uncertain or depends on environments not yet available. Play the question mark or push for a spike.
- Facilitate balanced discussion. If developers dominate and testers stay quiet, directly ask the testers for their estimate before reveal.
- Track whether the team's Planning Poker estimates are improving in accuracy over time. If velocity is stable but quality is dropping, estimates may be missing testing complexity.