Person holding playing cards on a white table, by Andrik Langfield on Unsplash
HomeBlogPlanning Poker rules: the complete guide

Planning Poker rules: the complete guide

Planning Poker June 4, 2026 By Julien

Everything you need to know to run a Planning Poker session: rules, roles, card values, step-by-step process, and tips for remote teams.

What is Planning Poker?

Planning Poker is a consensus-based estimation technique for agile teams. Invented by James Grenning in 2002 and popularized by Mike Cohn, it helps Scrum teams estimate the relative effort of user stories during sprint planning.

The principle is simple: every team member votes simultaneously using numbered cards. The simultaneous reveal prevents anchoring bias and encourages honest, independent thinking.

The official rules

Planning Poker does not have a single "official" rulebook, but the widely accepted rules come from Mike Cohn's Agile Estimating and Planning and the practices described in the Scrum Guide. Here is the standard process.

Who participates?

Three roles are involved:

  • Scrum Master: facilitates the session, manages the timer, reveals cards, and keeps the discussion on track.
  • Voters: the development team members who will actually work on the stories. They are the only ones who vote.
  • Observer: anyone who wants to follow the session without voting. Typically the Product Owner, a stakeholder, or a manager. They can ask questions but do not hold cards.

The Product Owner presents the stories but does not vote. Their presence is essential for context, but their estimate could influence the team.

The card values

The standard deck follows a modified Fibonacci sequence:

Card Meaning
0.5 Trivial task, nearly done
1 Very small effort, well understood
2 Small effort
3 Moderate effort
5 Medium effort, some unknowns
8 Large effort, significant complexity
13 Very large, consider splitting
21 Enormous, must be split before entering a sprint
? Not enough information to estimate
Coffee The team needs a break

The growing gaps between values reflect a fundamental truth: the bigger a task, the less precise your estimate can be. Distinguishing a 7 from an 8 is meaningless. Distinguishing a 5 from a 13 is meaningful.

Step-by-step process

Step 1: Present the story. The Product Owner reads the user story aloud, including acceptance criteria. The team asks clarifying questions. This phase should take 2-3 minutes at most.

Step 2: Silent estimation. Each voter privately selects the card that best represents the effort. No discussion, no peeking. This is where independent thinking happens.

Step 3: Simultaneous reveal. All cards are revealed at the same time. This is the core mechanism that prevents anchoring bias.

Step 4: Discuss divergences. If estimates differ significantly (for example, a 3 and a 13 in the same round), the voters at the extremes explain their reasoning. Common reasons for divergence:

  • Different understanding of the acceptance criteria
  • Hidden technical complexity one person spotted
  • Missing dependency or integration work
  • Different assumptions about scope

Step 5: Re-vote. After discussion, the team votes again. Most stories converge in 1-2 rounds. If a third round still shows wide divergence, the story probably needs to be refined or split.

Step 6: Record and move on. The Scrum Master records the agreed estimate and moves to the next story.

When to stop discussing

A common mistake is seeking perfect consensus. You do not need everyone on the same card. If the team narrows from a 3-13 spread to a 5-8 spread after discussion, that is sufficient. Take the higher value and move on.

A good rule of thumb: if the discussion exceeds 3 minutes on a single story, the story is not ready to be estimated. Set it aside for refinement.

Time management

Estimation sessions should be short and focused:

  • Target: 1-2 minutes per story on average
  • Session length: 60-90 minutes maximum before quality drops
  • Timer: use a 2-minute countdown per story to keep pace
  • Break: plan a 5-minute break every 45 minutes

If your team consistently exceeds these limits, the backlog likely needs better refinement before the estimation session.

Counting the votes

After the reveal, the facilitator can use several approaches:

  • Consensus: everyone shows the same card. Record it immediately.
  • Near-consensus: values within one step (e.g., 5 and 8). Take the higher value or the median.
  • Wide spread: values more than two steps apart (e.g., 3 and 13). Discuss and re-vote. Never average.

Never average estimates. "The average of 3 and 13 is 8" erases the very information Planning Poker is designed to surface: that the team disagrees about what this story involves.

Common mistakes

  1. Estimating in hours disguised as points. "It's a 5 because it will take 5 days." No. Story points measure relative complexity, not duration.

  2. Letting the senior developer go first. Even with simultaneous reveal, body language and timing can leak information. Strict simultaneous reveal eliminates this.

  3. Skipping the discussion after divergence. The discussion is where the real value lies. A silent re-vote without discussion is just averaging with extra steps.

  4. Estimating stories that are not ready. If the acceptance criteria are missing or vague, no estimation technique will help. Send the story back for refinement.

  5. Marathon sessions. After 90 minutes, estimation quality drops significantly. Two focused 45-minute sessions beat one 3-hour session.

  6. The Product Owner voting. The PO provides context but should not hold cards. Their vote, even unintentionally, can anchor the team.

Planning Poker for remote teams

Remote Planning Poker follows the same rules, but the tooling matters more:

  • Use a dedicated tool like Planning Poker Online so votes are truly hidden until reveal
  • Keep video cameras on so the Scrum Master can read the room
  • Use the built-in timer to maintain pace
  • Share the story description on screen, not just verbally
  • Consider async estimation for large backlogs: each voter estimates independently, and the team only discusses stories with divergent estimates

Read our dedicated article on Planning Poker for remote teams.

Planning Poker vs other techniques

Technique Best for Speed Precision
Planning Poker Sprint planning, 10-20 stories Medium High
T-Shirt Sizing Roadmap planning, large backlogs Fast Low
Affinity Mapping Initial backlog estimation, 30+ stories Fast Medium
Dot Voting Prioritization, not estimation Fast N/A
Bucket System Very large backlogs, 50+ stories Fast Medium

Planning Poker is the best choice when you need high-quality estimates on a manageable number of stories. For larger backlogs, start with T-Shirt Sizing or Affinity Mapping, then refine with Planning Poker as stories approach the sprint.

Quick reference card

  1. PO presents the story (2-3 min)
  2. Team asks questions
  3. Everyone picks a card in silence
  4. Simultaneous reveal
  5. If divergence > 2 steps: discuss extremes (2-3 min)
  6. Re-vote if needed (max 3 rounds)
  7. Record estimate, next story

Try it now

Ready to run your first session? Create a free Planning Poker session in seconds. No sign-up required, share the link with your team and start estimating.

Ready to estimate with your team?

Create your first session in 30 seconds. Share the link. Vote together. Free, no sign-up, forever.