What is planning poker?

What planning poker is (and what it isn't)

Planning poker is a group estimation technique: everyone votes in secret on how much effort a story takes, all cards turn at the same time and the team talks through the differences until it reaches a number everyone stands behind.

It is not a vote of opinions. The vote is a technical read on effort, complexity and uncertainty — and what matters is the conversation the reveal triggers, not the score.

It is also not a tool: paper cards, a spreadsheet or a room in the browser are different ways to hold the same ritual.

The outcome of the ritual isn't just a number: it's shared understanding. Two people with the same number and different understandings is a problem that shows up in the sprint, not in the estimate.

Where it came from

The name appeared in 2002, with James Grenning, and was popularized by Mike Cohn in the following years as part of the agile estimation toolkit. Its roots are older: the Delphi method, from the 1960s, already combined anonymous judgment with collective review.

Replacing Delphi's anonymity with a simultaneous reveal solved a practical part: the team talks face to face, but no one sees another's vote before recording their own.

The name “poker” came from the card mechanics, not the game itself: the idea was to give estimates the informality of a card table, with the same seriousness of outcome.

Why it works

Simultaneous voting prevents anchoring: no one adjusts their number to match whoever spoke first. When the first opinion becomes the final number, the estimate belongs to the most confident — or the fastest — not to the team.

Relative comparison does the heavy lifting. Teams estimate better by comparing stories with each other — “is this bigger than that?” — than by trying to measure in hours.

And the round turns disagreement into an agenda: instead of debating the estimate in the abstract, the team discusses exactly the points that pulled the votes apart.

There's also a calibration effect: by seeing teammates' votes and hearing their reasoning, each person adjusts their own yardstick. Within a few weeks, the team becomes more consistent without anyone studying a formula.

Secret voting also protects the less experienced: without the pressure of stares, the minority opinion shows up — and it's often the one that reveals the forgotten case.

None of this requires software: the ritual works with paper cards, and a tool only removes the setup.

When to use it (and when not to)

Use it in sprint planning, in backlog refinement and whenever the team needs to estimate new items together. It works best with described stories, even if some loose ends remain.

Don't use it when the deadline is already imposed from the outside — the estimate becomes theater — or on huge items nobody understands: a break and a spike (a time-boxed investigation) solve that first. Teams with no domain knowledge also estimate better after a refinement session.

A sign the timing is right: the item has acceptance criteria and still raises questions about size. If it raises no questions at all, the vote is quick; if the questions are about understanding, the place for them is refinement.

Done consistently, it also becomes a planning habit: the team learns to size work before committing to it.

The names: planning poker, scrum poker, estimation poker

They are the same ritual. “Planning poker” is the older name; “scrum poker” shows up when the team adopts Scrum and the session happens in sprint planning.

The context changes, not the mechanics: secret vote, simultaneous reveal, conversation and, if needed, another round. If your team uses the name scrum poker, the free scrum poker page shows the same flow in a Scrum context.

Scrum teams often call the session scrum poker even when the deck is the same as planning poker — the difference is in the ceremony, not the cards.

A practical example

The story is “Mobile checkout”. Bia votes 3, Caio votes 8, Dani votes 5 and you vote 5. At the reveal, Caio explains: he considered paying with two cards and the new integration that requires.

Bia realizes she missed that case. Dani remembers the team solved something similar on desktop checkout. In a quick second round, the votes converge on 5 — and the story keeps that number, now with the same understanding across the team.

What got recorded wasn't just the 5: it was the list of cases the team started to consider — two cards, link expiration. That library is what makes the next estimate faster.

How to apply it in 5 steps

1. Pick the story. Describe the context and acceptance criteria before any vote.
2. Open the room. Invite the people who build it: nickname, 4-character code and everyone is in within seconds, no signup.
3. Vote in secret. Everyone picks a card from the Fibonacci deck without seeing anyone else's.
4. Reveal and talk. Listen to the lowest and highest votes before defending your own number.
5. Close or repeat. Reach a number everyone stands behind or run a second round with what you learned.

The detailed walkthrough of a full session, with time per story and a script for disagreement, is in how to play planning poker.

If the team is new to the ritual, run the first session on stories already delivered: being wrong on known items is cheap and calibrates everyone's yardstick.

Frequently asked questions