What Is the Planning Poker Technique?

Planning poker is a consensus-based agile estimation technique that helps teams size user stories using a combination of structured process and open discussion. It is widely used in Scrum teams during sprint planning and backlog refinement sessions, and its combination of anonymity, simultaneous reveal, and structured debate makes it one of the most effective methods for producing honest, team-owned estimates.

The name comes from the physical card decks originally used, which resemble playing cards — but today, most teams use online tools that replicate the same mechanics without requiring everyone to be in the same room.

The Four Steps of Planning Poker

Step 1: Read the User Story

The facilitator — typically the Scrum Master — presents a user story to the team. The Product Owner is available to provide context, answer questions, and clarify acceptance criteria. At this stage, the goal is to ensure that every participant has a shared understanding of what the story involves before any estimation begins.

This step is often where valuable pre-estimation discussion happens. Team members may ask about edge cases, dependencies, or technical constraints. If a story is too vague or undefined to discuss meaningfully, it should be sent back to the Product Owner for further refinement rather than estimated under uncertainty.

Step 2: Estimate Anonymously and Independently

Once the team feels they have a sufficient understanding of the story, each team member privately selects a card from their deck that represents their estimate of the story’s relative complexity. The card values typically follow the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, and sometimes higher values or special cards like ∞ (too large to estimate) or ? (not enough information).

The critical requirement at this stage is that estimates are formed independently, without influence from other team members. No one shares their number, no one hints at their card, and body language is kept neutral. This independence is what makes planning poker effective — it preserves the diversity of perspectives that a purely discussion-based approach would erode.

Step 3: Reveal Simultaneously

When everyone has made their selection, the facilitator calls for the reveal. All team members show their cards at the same moment. This simultaneous reveal is the mechanism that prevents anchoring — the well-documented cognitive bias where people adjust their judgment toward the first number they hear.

If all estimates are identical or very close together, consensus is reached quickly and the team records the estimate and moves to the next story. If estimates vary significantly, the session moves to the most important step.

Step 4: Discuss Until Consensus Is Reached

When estimates diverge, the team discusses. The participants who gave the highest and lowest estimates are typically asked to explain their reasoning first. This structured discussion surfaces different assumptions, hidden risks, and knowledge gaps that might not have emerged from a simple group discussion.

After the discussion, the team votes again. This process repeats until the team reaches a consensus estimate — or until they decide to split the story into smaller, more manageable pieces and estimate each separately. The goal is not to force agreement through compromise, but to reach a shared understanding of the work.

Who Should Participate?

The development team forms the core of a planning poker session. These are the people who will actually build the product, and their estimates should reflect their collective understanding of the technical complexity involved. Including all relevant disciplines — developers, QA, UX, and any other roles contributing to the story — produces more accurate and complete estimates.

The Product Owner is present but typically does not vote. Their role is to define what is needed, answer questions, and clarify acceptance criteria. Having the Product Owner available in real time dramatically reduces the number of ambiguous stories that have to be deferred for later refinement.

The Scrum Master facilitates the session — keeping time, managing the process, and ensuring that the rules (especially the simultaneous reveal) are followed. An effective Scrum Master creates space for quieter team members to share their estimates and prevents dominant voices from steering the group before the cards are shown.

Why Planning Poker Works

Planning poker is effective because it combines the wisdom of crowds with structured process controls. By requiring independent private estimates before any group discussion, it captures a broader range of perspectives than a simple show-of-hands or top-down approach. By requiring discussion whenever estimates diverge, it ensures that disagreements are addressed rather than papered over.

The result is estimates that the whole team understands and owns — which is ultimately more valuable than any single expert’s prediction.