The core idea
Planning poker — also called scrum poker or poker planning — is a consensus-based estimation method used during sprint planning and backlog refinement. Each team member privately selects a card representing how much effort they think a user story will take, then everyone reveals at the same time. Wide disagreement is the signal to discuss, not a problem to average away.
Why "simultaneous reveal" matters
Sequential estimation invites anchoring: the first number shapes everyone else's. Planning poker forces independent thinking first and conversation second. That's where the value comes from — not the number itself, but the 10-minute discussion that happens when one engineer voted 3 and another voted 13.
How a session typically runs
- Present the story. Read the title, acceptance criteria, and context.
- Q&A. The team asks clarifying questions until the story is understood.
- Vote. Everyone picks a card privately.
- Reveal. Cards flip at the same time.
- Discuss outliers. The highest and lowest estimators explain their reasoning.
- Re-vote if needed. Repeat until the group converges — usually in one or two rounds.
- Record the final estimate and move to the next story.
What the cards mean
Planning poker decks intentionally skip values to reflect real uncertainty. Common decks:
- Fibonacci — 1, 2, 3, 5, 8, 13, 21, 34 (most common).
- T-shirt sizes — XS, S, M, L, XL, XXL.
- Powers of 2 — 1, 2, 4, 8, 16, 32.
- 0 and ? — trivial / too ambiguous to estimate.
For the trade-offs between these, see Fibonacci vs T-shirt sizing.
Who plays
Everyone who will work on the story — engineers, designers, QA — votes. The product owner or scrum master typically does not vote; they facilitate. Observers can watch, but the goal is team alignment, not democratic averaging.
Running it remotely
In a co-located team, planning poker uses physical cards. For remote or hybrid teams, you need a real-time tool where votes stay hidden until everyone has voted. Pokor is built for that: import your Jira backlog, share a link to the session, vote together, and launch it from Slack if your team already lives there. See planning poker for remote teams for the full remote-specific playbook.
Common pitfalls
- Averaging outliers. The conversation is the point. Don't just average 3 and 13 into 8 and move on.
- Treating estimates as commitments. Story points measure relative effort, not time. A sprint commits to a set of stories, not the sum of their points.
- Estimating too far ahead. Effort estimates for stories two sprints out are usually wasted work. Estimate what you're about to commit to.