What is Planning Poker?

The short definition

Planning Poker (also called Scrum Poker) is a technique where each team member selects a card representing how much effort they think a backlog item requires. Cards stay hidden until everyone has voted, then all cards are revealed simultaneously. If the estimates agree, the number is recorded. If they don't, the highest and lowest voters explain their reasoning and the team votes again.

The method was described by James Grenning in 2002 and popularised by Mike Cohn in Agile Estimating and Planning. It is now one of the most widely used estimation practices in Scrum and Kanban teams.

Why simultaneous reveal matters

The single most important rule is that nobody sees another person's estimate before their own is locked in. This removes anchoring bias — the well-documented tendency to adjust your judgement toward the first number you hear. When a tech lead says "this is a 3" out loud, the rest of the room converges on 3, and the team loses the information it actually came for.

Divergent votes are not a failure of the process. They are the signal: a 2 next to a 13 almost always means two people are describing different pieces of work.

What the numbers mean

Story points measure relative effort, not hours. A point bundles three things together:

• Volume — how much work there is.
• Complexity — how hard the work is to reason about.
• Uncertainty — how much you don't yet know.

Because points are relative, a team's velocity only makes sense within that team. Compare a team to itself over time; never compare points across teams.

How a session runs, step by step

1. Pick a reference story. Choose a well-understood item everyone agrees on and call it a 3 (or a 5). Every other estimate is made relative to it.
2. Read the item. The Product Owner presents the story and acceptance criteria.
3. Ask questions. Time-box clarification to two or three minutes.
4. Vote privately. Everyone selects a card at the same time.
5. Reveal together. All cards flip at once.
6. Discuss the outliers. Highest and lowest explain first — that's where the hidden assumptions live.
7. Re-vote. Usually one extra round is enough. If a third round doesn't converge, the story is too vague or too big — split it.

The special cards

• 0 — trivial, or already done as part of something else.
• ? — "I don't have enough information to estimate." A single ? should pause the vote, not be averaged away.
• ☕ (coffee) — "I need a break." Estimation fatigue produces bad numbers; treat it as a legitimate vote.
• The largest card (21, 100 or XXL) — "this is too big to estimate." The right response is to split the story, not to guess.

Common mistakes

• Converting points to hours. Doing so reintroduces every problem relative estimation was meant to solve.
• Averaging the votes. The average hides the disagreement that made the session worthwhile. Discuss and re-vote instead.
• Estimating with a partial team. Everyone who will do the work should vote, including QA and design.
• Marathon sessions. Beyond 60–90 minutes accuracy drops sharply. Split the backlog across sessions.
• Using points as a performance target. As soon as points are a KPI, they inflate and stop being useful for forecasting.

Running it with a remote or hybrid team

Physical card decks do not survive video calls: someone always reads the chat before voting. An online tool enforces the hidden-vote rule automatically, keeps a history of rounds, and gives everyone the same view regardless of location.

With Planner Poker you create a room, share a six-character code or link, and teammates join instantly from any device — no account and no install. Votes sync in real time, cards reveal together, and the average, minimum and maximum appear the moment the round ends.

How long should estimation take?

A healthy rhythm is around two minutes per story, including discussion. If a single item consumes ten minutes, the problem is the story, not the process — split it, spike it, or park it until the unknowns are resolved.