What is planning poker?
Planning poker is a consensus-based agile estimation technique: teams vote privately, reveal every card at once, and discuss the spread until the estimates converge.
Planning poker is a consensus-based estimation technique: the team sizes a piece of work by voting privately, revealing every card at once, and discussing the disagreement the reveal exposes. When the cards converge, that number is your estimate.
It sounds almost too simple to matter, and the simplicity is the point. Because the vote is private and everyone reveals at the same moment, nobody anchors on the first number said aloud — and any real disagreement about the size of the work actually surfaces, instead of being quietly smoothed into the loudest person’s guess.
How a round works
A round has four beats. The facilitator reads the item and the team asks clarifying questions. Everyone plays a card at the same time — face-down in the room, hidden automatically in a tool. The cards flip together. If they disagree by more than a step, the highest and lowest cards explain their reasoning, and the team re-votes. Most items settle inside two votes; the full facilitator’s loop is its own chapter.
Where planning poker came from
James Grenning wrote it up in 2002, looking for something quicker than Wideband Delphi — a structured estimation process descended from 1940s RAND work, and about as ceremonial as that sounds. Mike Cohn’s 2005 book Agile Estimating and Planning put it in front of the wider Scrum world, and it has been standard kit ever since. The name is literal: estimators play numbered cards like a hand, face-down, and turn them over together.
Why the cards use the Fibonacci sequence
Most decks run a Fibonacci sequence — 1, 2, 3, 5, 8, 13, 21 — and the gaps widen on purpose. The bigger the work, the less anyone actually knows about it, so the options spread apart to match. You end up choosing between an 8 and a 13 instead of arguing over whether something is a 9 or a 10. That argument was never going to be accurate; the scale simply stops you having it. There’s a whole chapter on why Fibonacci if you want the reasoning in full.
What you’re estimating: effort, not time
Planning poker sizes relative effort, not hours. A story point bundles three things — complexity, uncertainty, and sheer amount of work — into one number. A 5 is roughly five times the effort of a 1, even when nobody in the room can tell you how many hours either one takes.
That’s the point, not a limitation. People are unreliable at predicting clock time and surprisingly good at saying this is bigger than that. Planning poker leans on the judgement teams are actually good at and ignores the one they’re not. (When someone asks you to convert the points back into hours, read story points vs hours before you agree to it.)
Why teams use it
A few things fall out of the private-vote mechanic that are hard to get any other way:
- It surfaces disagreement instead of hiding it. When one engineer plays a 2 and another plays a 13, you’ve found a gap in shared understanding. An average would have buried it at 8 and shipped the confusion into the sprint.
- It prices the whole cost of shipping. Designers, QA, and engineers all vote, so the estimate reflects testing, edge cases, and design work — not just the coding.
- It flattens seniority at the vote. A junior’s hidden card counts exactly as much as the lead’s. Seniority earns its keep in the discussion after the reveal, which is where it belongs.
- It’s quick. A focused team sizes ten to fifteen refined stories in half an hour, and the numbers tend to be more honest than the ones people give under social pressure.
When planning poker is the wrong tool
Planning poker is the right call when you need shared understanding, not just a number — a focused backlog of stories the team is about to commit to. It’s the wrong call when you have hundreds of items and need rough sizing fast; reach for bucket sizing, affinity mapping, or T-shirts instead. And if your stories are already small and uniformly understood, you may not need to estimate them at all — plenty of mature teams drift toward simply counting stories once their refinement is sharp. Planning poker is a tool for a specific job, not a ritual to perform every sprint regardless.
When you’re ready to run a round, TeamRetro’s free planning poker keeps every vote hidden until the reveal, so the mechanic works the same for a distributed team as it does around a table. New to facilitating one? Start with how to run a session.
Frequently asked questions
How does planning poker work?
The team sizes one item at a time. The facilitator reads it, everyone votes privately with a numbered card, and all the cards are revealed at once. If they disagree, the highest and lowest estimators explain their reasoning and the team re-votes. When the cards land within a step of each other, that number is the estimate — usually within two rounds.
What is the Fibonacci sequence used in planning poker?
Most decks use 1, 2, 3, 5, 8, 13, 21 and up. The gaps widen on purpose: the larger the work, the less precisely anyone can size it, so the scale offers fewer, wider choices at the top and removes the false-precision argument about whether something is a 9 or a 10.
When should a team use planning poker?
Use it for a focused set of well-refined stories the team is about to commit to, where shared understanding matters as much as the number. For sizing a large backlog quickly, a faster technique such as bucket sizing or affinity mapping fits better. Planning poker trades speed for the conversation it forces.
Does planning poker actually work?
It works when the stories are refined and someone protects the mechanic — private votes, a real discussion on wide spreads, and no averaging. It fails quietly when teams estimate vague stories or convert the points straight back into hours. The technique is robust, but it is not automatic; see planning poker mistakes for the ways it goes wrong.