Create a Room
← Back to Planning Poker

Guide

How to Run a Planning Poker Session

Planning poker is one of the most effective estimation techniques available to agile teams, but only when it's run well. This guide covers everything from preparing your backlog to closing a session with clean, usable estimates.

Why planning poker works

The core insight behind planning poker is preventing anchoring bias. When estimates are discussed openly (for example, "I think this is an 8"), everyone's subsequent vote is influenced by that number, even subconsciously. Planning poker requires every participant to commit to an estimate privately before anyone sees the others. Cards are revealed simultaneously, which means every number on the table reflects independent thinking.

When estimates diverge, that divergence is information. It means different people hold different mental models of the story: different assumptions about scope, complexity, or implementation approach. Surfacing those differences before the sprint is far cheaper than discovering them mid-sprint.

Before the session: what to prepare

A planning poker session runs smoothly when the groundwork is done ahead of time.

  • Groom your backlog first. Planning poker estimates ready stories, not ideas. Each item should have a clear acceptance criterion and enough detail for the team to reason about its scope. Estimating vague stories wastes the session and produces unreliable numbers.
  • Choose the right deck. Fibonacci (1, 2, 3, 5, 8, 13, 21…) is the standard choice for sprint planning, giving enough resolution for capacity decisions without false precision on large items. T-shirt sizing (XS to XXL) is faster for rough backlog ordering.
  • Keep it to 10–15 items. Focused sessions (60–90 minutes) produce better estimates than marathon ones. If you have more stories than that, split the work across two sessions or use T-shirt sizing to triage first.
  • Invite the right people. Voting participants should be engineers who will do the work. Product owners, Scrum Masters, and stakeholders can join as spectators to observe and answer questions without influencing the vote.

Running a round: step by step

1

Present the story

The dealer reads the story aloud and shares any relevant acceptance criteria. Participants ask clarifying questions, but no one estimates yet.

2

Set a round label (optional)

Give the round a ticket ID or short name (e.g. "AUTH-42: password reset flow"). This label appears in the session history and makes exported CSVs meaningful later.

3

Everyone votes privately

Each participant selects a card. No one can see anyone else's choice until the dealer triggers the reveal. Take as long as needed. This is the most important step.

4

Simultaneous reveal

The dealer reveals all votes at once. If estimates are close (e.g. all 5s and 8s), accept the consensus or take the mode. If there's wide spread, move to discussion.

5

Discuss outliers

The highest and lowest voters explain their reasoning, not to defend their number, but to share what they were considering. This is where hidden complexity gets surfaced. Timebox this to 2 minutes.

6

Re-vote if needed

After discussion, re-vote. Most teams reach consensus within two rounds. If the team still can't agree after a second round, the story is probably not ready. Table it and add a refinement action.

7

Record and move on

The final estimate is recorded in the session history. Export the CSV at the end of the session and paste the story points into your backlog tool.

Best practices

Timebox discussions

Two minutes per outlier discussion is enough. If you need more time, the story probably needs more refinement, not more debate. Set a visible timer and move on when it ends.

Don't estimate what you don't understand

If a story generates more questions than estimates, it's not ready. Log the open questions, assign someone to clarify them, and bring the story back next session. Forcing an estimate on a vague story produces a meaningless number.

Use the spectator role for stakeholders

Product owners, designers, and other non-engineering stakeholders should join as spectators. They can answer questions about requirements and observe the discussion without casting votes that skew the team's technical assessment.

Keep sessions under 90 minutes

Estimation fatigue is real. After about 90 minutes, the quality of estimates degrades noticeably. If you have a large backlog to groom, break it across multiple shorter sessions rather than one exhausting one.

Ready to run your first session?

Create a free room in seconds. No account required.

Start a Free Room →