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.
Industry Reality
- Most teams skip full Planning Poker for stories under 3 points — a quick thumb-up or verbal agreement is common, and that's fine. The ceremony is reserved for anything uncertain or large.
- Digital tools like PlanningPoker.com have largely replaced physical cards in NZ distributed teams, but the simultaneous reveal mechanic is frequently bypassed when the facilitator just asks "what did everyone get?" — reintroducing exactly the anchoring bias the technique was designed to prevent.
- In many organisations, velocity commitments are negotiated with management after estimation, meaning estimates made in good faith during Planning Poker get quietly rounded down before sprint commitment. Senior practitioners learn to estimate honestly and let the negotiation happen separately.
- Experienced Scrum Masters often timebox individual story discussions to 3–5 minutes and move unresolved items to a parking lot for offline clarification rather than letting the session run to two hours — something the textbook doesn't emphasise enough.
- In practice, the "? card" is underused. Teams feel social pressure to produce a number. Normalising "I cannot estimate this without a spike" is a sign of team maturity, not weakness.
Context guide
How the right level of Planning Poker effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government digital services (Revenue NZ, Benefits NZ, TransitNZ) estimating stories with legislative constraints or compliance deadlines | Essential | Regulatory-driven stories carry hidden testing complexity (compliance verification, audit trails, edge cases from legislation) that developers rarely see without testers estimating alongside them. Divergent estimates expose this gap before sprint commitment. |
| Mixed NZ/offshore distributed teams (e.g. Auckland product owner, Wellington developers, Manila QA) | Essential | Timezone gaps mean async estimation is tempting but lossy. Synchronous Planning Poker with a digital tool (PlanningPoker.com or Jira plugin) surfaces the disagreements that async Slack votes miss entirely, especially around environment and deployment assumptions that differ between NZ and offshore contexts. |
| Mid-size NZ SaaS product team (4–8 people, 2-week sprints, stable backlog) | High | Small NZ team sizes mean a single absent engineer meaningfully changes the estimate distribution. Planning Poker's structured reveal forces the team to name that gap explicitly rather than quietly absorbing it into a consensus number. |
| Early-stage NZ startup in discovery phase, stories still exploratory and frequently rewritten | Medium | Stories are too fluid for Fibonacci precision; T-shirt sizing or even no formal estimation is lower friction. Reserve Planning Poker for stories that have graduated from discovery and have acceptance criteria the team can discuss concretely. |
| Solo contractor or 2-person team embedded at a client site (common in NZ SME market) | Low | The consensus mechanic provides no value below three independent estimators. Use a shared reference story baseline and a quick verbal check-in instead; Planning Poker's ceremony adds overhead that a micro-team cannot justify. |
| Team running #NoEstimates or Kanban with flow metrics (cycle time, throughput) as the planning mechanism | Low | Flow metrics already provide probabilistic forecasts from historical data. Adding Planning Poker creates duplicate overhead without adding meaningful signal. Only reintroduce it when the team encounters a large novel workstream with no historical comparator. |
Trade-offs
What you gain and what you give up when you adopt Planning Poker.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Surfaces hidden complexity before sprint commitment — testers and developers often hold completely different mental models of the same story, and the card reveal makes that visible instantly. | Adds 30–90 minutes per refinement session. On long backlogs with 20+ stories, the cumulative ceremony cost is non-trivial, especially for NZ teams billing time to government or enterprise clients who scrutinise meeting overhead. | You have more than 15 stories to size in a single session — use T-shirt sizing for the initial pass and reserve Planning Poker for the top-priority items only. |
| Prevents anchoring bias — simultaneous reveal means no single voice (including the tech lead) sets the reference point before others have committed to their own judgement. | Requires psychological safety to work correctly. In NZ workplace cultures where deference to seniority is common — particularly in teams with a strong tech lead or engineering manager in the room — juniors still fold after reveal, defeating the independence mechanic. | Your team lacks psychological safety — first invest in retrospectives and facilitation practices that normalise dissent before introducing Planning Poker, or the tool will simply disguise the same dynamics with extra steps. |
| Builds shared understanding and vocabulary across roles — the discussion phase is where testers, developers, and BAs calibrate their mental models of scope, and that calibration compounds positively across sprints. | Velocity produced from Planning Poker estimates is only comparable within the same team. Cross-team velocity comparisons (common in NZ enterprise portfolio reporting) are meaningless and create perverse incentives to inflate or deflate estimates for political reasons. | Leadership is using your velocity numbers to benchmark teams against each other — replace story points with flow metrics (throughput, cycle time) that are measurement-invariant across teams and resistant to gaming. |
| Gives QA testers a structural voice in sprint scope decisions — playing a card forces a tester's view of effort into the conversation in a way that informal backlog review does not. | Estimates are relative to a reference story, so if the reference story was poorly chosen or forgotten, the entire scale drifts. NZ teams that run Planning Poker for 6+ months without anchoring to a stable reference story often find their velocity numbers incomparable across quarters. | Your scale has drifted and velocity is no longer meaningful — run a deliberate re-calibration session where the team re-estimates 5–6 well-understood completed stories to re-anchor the scale before resuming sprint Planning Poker. |
Enterprise reality
How Planning Poker changes when 200–300 developers are estimating across 10+ squads in NZ banks, government agencies, and telcos
- Estimation is automated at scale: organisations such as Pacific Bank use Jira Agile Poker integrated with their backlog toolchain so that every estimate is captured, time-stamped, and visible in portfolio dashboards — no one manually records session outcomes, and Jira's historical data feeds quarterly planning forecasts automatically.
- Governance and audit requirements change the stakes: under the NZISM (New Zealand Information Security Manual) and PCI DSS mandates that apply to NZ banks and payment processors, estimation sessions touching security controls, access management, or cardholder data systems must produce documented artefacts — the Planning Poker record in Jira becomes part of the change-management audit trail, not just a planning convenience.
- At 10+ squad scale, tooling consistency is non-negotiable: TechServNZ and TeleNZ run standardised Jira plugin configurations across all squads so that velocity numbers, estimation scales, and reference stories are governed centrally — individual squads cannot choose their own Fibonacci variants or switch tools, because cross-squad portfolio reporting breaks the moment estimation units diverge.
- Multi-timezone coordination introduces estimation lag that small teams never encounter: when a squad is split across Wellington, Auckland, and an offshore delivery partner in Manila or Hyderabad, synchronous Planning Poker requires a scheduled estimation window that works across time zones — in practice this compresses backlog refinement cycles, and stories that miss the window either get async-estimated (reintroducing anchoring bias) or pushed to the next sprint, costing a full fortnight of lead time for a single missing estimate.
◆ What I would do
Professional judgement — when to adopt Planning Poker, when to adapt it, and what to watch for.
The bottom line: Planning Poker is a structured disagreement protocol, not a consensus ritual — its entire value comes from the team's highest and lowest estimates being taken seriously rather than smoothed away, and any process change that suppresses outlier voices (social pressure, authority in the room, premature reveal) eliminates exactly the signal the technique was designed to surface.
Best Practices
- ✓ Enforce simultaneous reveal strictly — use a countdown ("3, 2, 1, show") or lock cards in a digital tool until everyone has submitted.
- ✓ Always ask the highest and lowest outliers to speak first, even when the spread is only 1–2 points apart. That lone 5 in a sea of 3s often holds the team's only risk signal.
- ✓ Timebox each story to 5 minutes maximum. Set a visible timer. If consensus isn't reached, take the higher number and move on.
- ✓ Treat the ? card as a legitimate answer. When someone plays it, the right response is to schedule a spike — not to pressure them into guessing.
- ✓ Use a reference story as a baseline anchor. Pin a well-understood completed story (e.g., "adding a new field to the profile form = 2 points") to calibrate new estimates against.
- ✓ Include testers and QA in every round. Testing complexity is invisible to developers until a tester raises it; excluding QA from estimation leads to chronically optimistic delivery forecasts.
- ✓ Review estimation accuracy each retrospective. Compare planned points to actual delivery; use the gap to recalibrate your team's scale, not to blame individuals.
- ✓ Split any story that consistently attracts 13+ before it enters the sprint. Agreeing to split is a valid Planning Poker outcome — it is not a failed session.
Common Misconceptions
❌ Myth: Story points are just hours in disguise — a 5-point story takes about 5 hours.
Reality: Story points measure relative complexity, risk, and uncertainty — not time. Two stories can both be 5 points and take wildly different calendar hours depending on context, tooling, and who is working on them. Teams that try to convert points to hours directly undermine the flexibility that makes the technique useful.
❌ Myth: The goal of Planning Poker is to reach a fast consensus number so the team can move on.
Reality: The goal is shared understanding of the story. A session where the team reaches a number quickly but with no discussion has often produced a false consensus — everyone assumes the story is the same as their mental model, when it isn't. The number is a side effect; the conversation is the product.
❌ Myth: Managers and product owners should participate in Planning Poker to make sure estimates are realistic.
Reality: Product owners answer questions and clarify scope — they do not vote. Managers should not vote at all. When authority figures play cards, team members unconsciously calibrate toward those numbers, destroying the independent-judgment mechanic that makes Planning Poker work. The PO's job is to inform the estimate, not influence it.
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.
Senior engineer insight
Teams who do Planning Poker well treat the discussion as the deliverable, not the number. The clearest signal of a high-performing team is that they use divergent estimates as a diagnostic — a 3-versus-8 spread means the story has a hidden complexity that needs to surface before sprint commitment, not a social problem to smooth over. The single pattern that separates great estimation sessions from mediocre ones is consistently asking the highest outlier to speak before any re-vote: that person almost always holds the risk the rest of the team hasn't considered.
The most common mistake teams make when adopting Planning Poker is treating the simultaneous reveal as optional — letting the tech lead place their card first "just to get things moving" reintroduces exactly the anchoring bias the whole technique was designed to eliminate.
From the field
A Wellington-based six-person scrum team building a digital forms platform for a government agency ran Planning Poker for six months and consistently delivered within one or two points of their estimates — until they started a major sprint. The team's lead developer had quietly been estimating all the API integration stories himself before the session and anchoring the room with a number before cards were selected, which the Scrum Master only noticed when reviewing session recordings. When they enforced strict simultaneous reveal using PlanningPoker.com, the testers — who had been deferring to the developer — started playing cards two to three points higher on any story touching the legacy SOAP gateway, because the regression surface was invisible to the developers but obvious to QA. The broader lesson: testers carry estimation signal that developers structurally cannot see, and any process that accidentally silences them is producing optimistic forecasts, not honest ones.
Why teams fail here
- Anchoring before the reveal — a senior or the Scrum Master says "I'm thinking this is a 5" before cards are shown, collapsing independent judgment into social agreement before discussion even starts.
- Excluding testers or treating QA estimates as optional — developers estimate implementation effort and silently assume testing is overhead, producing sprint commitments that have no room for regression, automation, or exploratory testing cycles.
- Skipping discussion when estimates appear close — a spread of 3, 3, 5 looks like near-consensus, but that lone 5 is often the only voice flagging a downstream dependency or an environment constraint that will blow the sprint.
- Letting management attend as voters — when a product owner, delivery manager, or CTO plays a card, the team unconsciously converges toward that number regardless of their own reasoning, turning Planning Poker into a negotiation rather than an estimation exercise.
Key takeaway
Planning Poker done well is not an estimation ceremony — it is a structured disagreement protocol that turns hidden assumptions into shared understanding before they become sprint failures.
How this has changed
The field moved. Here is how Planning Poker evolved from its origins to current practice.
James Grenning invents planning poker. The insight: independent simultaneous estimates reveal disagreement better than sequential estimation, which causes anchoring bias. The card reveal eliminates anchoring.
Mike Cohn popularises planning poker in "Agile Estimating and Planning." Fibonacci-sequence card decks (1, 2, 3, 5, 8, 13...) become a standard agile team artefact.
Digital planning poker tools enable remote teams to estimate simultaneously. Physical card decks remain popular for co-located teams. The practice becomes ubiquitous across agile shops.
The #NoEstimates movement challenges story points. Flow metrics (cycle time, throughput) are argued to provide better forecasts than estimation without the ceremony. Planning poker faces its first serious challenge.
AI-assisted estimation tools suggest story point ranges from historical data. Some teams use planning poker to calibrate AI suggestions rather than estimate from scratch. The relative estimation conversation remains valuable even as alternatives exist.
Self-Check
Click each question to reveal the answer.
Q: Your sprint team is estimating a user story to add KiwiSaver contribution rate changes to an Revenue NZ employer portal. The story is well understood by two developers but a key backend engineer is on leave. The team is split between 5 and 8 points. What should you do?
A: Defer the estimate until the absent engineer is available. KiwiSaver contribution logic involves legislative rules and potentially downstream tax calculations that the backend engineer may have critical context on — estimating without them risks locking in a number that is wildly optimistic. Playing a ? card and scheduling a brief async estimate when they return is more honest than forcing a 5-vs-8 consensus that may collapse the moment the real complexity is understood. This is especially true in NZ government portals where regulatory-driven changes carry compliance risk that inflates testing effort beyond what developers typically anticipate.
Q: What is the key difference between Planning Poker and T-shirt sizing, and when would you choose one over the other?
A: Planning Poker uses a numerical scale (typically Fibonacci) and enforces independent simultaneous reveal, making it precise enough for sprint-level estimation and tracking velocity over time. T-shirt sizing uses broad relative buckets (S/M/L/XL) and is faster and lower-friction, making it more suitable for early backlog grooming, product roadmapping, or cross-team prioritisation where exact numbers are premature. Choose Planning Poker when the team is sprint-planning stories that will be committed to in the next one or two iterations. Choose T-shirt sizing when you need a rough sense of scale across many epics or features at the portfolio or discovery phase, before stories are well enough defined to warrant Fibonacci precision.
Q: When should you NOT use Planning Poker?
A: Planning Poker adds overhead that is not always justified. Avoid it when: a story is trivial and the entire team would obviously play a 1 (verbal agreement is faster); the team has already estimated a near-identical story and nothing has changed; the product is in discovery and stories are too undefined to estimate reliably (use a spike or a higher-level sizing technique instead); or the team is under two people, where the "consensus" mechanic provides no value. On fast-moving NZ startup teams or solo contractors embedded in a client site, forcing Planning Poker for every backlog item creates ceremony without benefit — the goal is shared understanding, and a five-second verbal check-in achieves that just as well for obvious work.
Q: A developer on your team says "The PO gave us detailed wireframes and acceptance criteria, so Planning Poker is just a formality — I already know it's a 3. Can we just agree and move on?" What is wrong with this reasoning, and how do you respond?
A: The developer is conflating functional clarity with effort certainty. Detailed acceptance criteria tell you what the feature must do, but they do not reveal testing complexity, backend dependencies, regression risk, or integration surface area that only emerge when the full team estimates. A tester may see a 3-point front-end story as an 8 because of regression coverage on the RealMe identity integration it touches. Skipping the reveal removes that signal. The right response is to run the round quickly — "Let's each pick a card and reveal; if we all agree it's a 3, we're done in thirty seconds." If everyone agrees, the ceremony takes thirty seconds. If someone plays a different number, you just discovered something worth knowing.