How planning poker works
Planning poker is a consensus-based way to estimate backlog items. Each person gets the same deck of numbered cards, the team talks through a user story, and everyone shows a card at the same moment. When the numbers disagree, the people at the extremes explain their thinking and the team votes again. The simultaneous reveal is what makes the method work: in an ordinary estimation meeting, the first number said out loud has a way of becoming the answer, and planning poker takes that first number away.
Where planning poker came from
The roots go back to the Delphi method, developed at the RAND Corporation in the 1950s and 60s. A panel of experts answers a question anonymously, sees a summary of the group’s answers, and revises over several rounds. In the 1970s Barry Boehm and John Farquhar adapted it for software estimation as Wideband Delphi, adding discussion between the rounds.
Planning poker is a lighter, faster descendant. James Grenning described it in a short paper in 2002, as a way to estimate in agile release planning without the process dragging on. Mike Cohn’s book Agile Estimating and Planning (2005) covers the technique in a section of its chapter on estimating techniques, and the book did a lot to spread it through Scrum and XP teams. Most teams now use it to put story points on their backlog.
The rules, step by step
A typical round goes like this:
- Everyone gets a deck. The usual one is a modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, plus “?” and a coffee cup. The gaps widen as the numbers grow, for reasons covered on the Fibonacci planning poker page.
- The product owner reads the story and explains what the user needs, along with the acceptance criteria.
- The team asks questions. Enough to size the story, not enough to design it.
- Everyone picks a card privately. No hints, no “I’m thinking low”.
- All cards are revealed together.
- If the votes are close, record the number. A spread of 5, 5, 5, 8 usually settles on 5 after a sentence or two.
- If they’re far apart, the highest and lowest voters speak first, and then the team votes again.
Most stories settle in one or two rounds. When a third round still shows a wide spread, more voting rarely helps. The story needs more information, or it needs to be split into smaller pieces.
Only the people who will build the thing vote. In most teams the product owner answers questions but doesn’t pick a card; a manager sitting in on the session shouldn’t either.
An example round: a 3 and a 13
Here’s a story a web team might pick up on a Tuesday afternoon: “As a customer, I want to download my invoices as PDF so I can send them to my accountant.”
The product owner explains that invoices already appear on the account page and the ask is a download button. The team has two questions. Which invoices? All of them, back to 2019. Does the PDF need to look like the printed invoice? Roughly, yes.
Five developers vote, and the cards come up 3, 3, 5, 5, 13.
Priya played the 13 and Tom one of the 3s, so the facilitator asks them to go first.
Tom: “We already generate PDFs for order confirmations. I assumed we’d reuse that template engine and add an endpoint. A day, maybe two.”
Priya: “Invoices before 2022 live in the old billing system, and their line items are in a different format. Someone has to write a mapper for the legacy data, and we have no test fixtures for it.”
Nobody else knew about the legacy invoices. The product owner confirms the older ones matter, since accountants often ask for several years of history.
Second vote: 8, 8, 8, 13, 8.
The team records 8 and adds a note about the legacy mapper. Priya’s lingering 13 is worth taking seriously, and plenty of teams would split the story at this point: recent invoices in one story, the legacy import in another. Either way, the estimate on the backlog now accounts for a risk that only one person had spotted. If Tom had said “easy, a 3” before anyone voted, there’s a fair chance the story would have gone into the sprint at 3 and blown up halfway through.
Common mistakes
Anchoring
Any number spoken before the reveal pulls the votes toward it. “This feels like a 3, right?” does it, and so does a product owner saying “this should be quick”. In a physical room people hold their cards face down. Online, the tool has to hide the values until everyone reveals, and ideally shouldn’t send them to other people’s screens at all before then.
Seniority pressure
Juniors often move their vote toward the tech lead’s, either in the first round or in the re-vote once they’ve seen what the lead played. Disagreeing with the most experienced person in the room feels risky. A facilitator can take some of the pressure off by always asking the lowest and highest voters to talk first, whoever they happen to be. In the example above, the outlier was the only person who remembered the legacy system.
Estimating a story that isn’t ready
When the team keeps asking questions nobody can answer, voting anyway produces a number that looks precise and means very little. Someone should play “?”, and the story should go back to refinement. Five minutes of clarification next week costs far less than discovering a missing requirement mid-sprint. The non-numeric cards are covered in more detail on the Fibonacci page.
Averaging the spread away
With votes of 2, 3 and 13 it’s tempting to take the average, call it 5 and move on. The average hides exactly what you need to know, which is that one person sees a risk the others don’t. Talk it through, then vote again.
Discussing forever
Some teams swing the other way and spend twenty minutes on one story. A workable rule is two rounds, then agree, split or defer. A story that can’t converge after two rounds of discussion usually has a problem that more talking in this meeting won’t solve.
Running planning poker remotely
Distributed teams can’t hold up physical cards, and typing numbers into the meeting chat brings anchoring straight back, because whoever types first sets the tone for everyone after. What you need is a shared place where each person can vote privately and the cards flip together.
In practice a remote session looks like this. The facilitator creates a room and drops the link into the video call. The story is shared on screen so everyone reads the same text. People pick cards in the room, which shows who has voted but not what they picked. Once the last vote is in, someone reveals the cards, and the discussion happens on the call. For a re-vote, the facilitator starts a new round, which clears the previous cards.
SprintPoker works this way in the browser, with no sign-up; the about page lists what it does and doesn’t do.
A couple of small habits make remote sessions go better. Ask the facilitator to read the results aloud after each reveal, since people have different windows in front and not everyone is looking at the room. Keep sessions short, too. Estimation over video wears people out faster than in person, and a tired team starts rounding everything to 5 just to finish.
Planning poker and Scrum
Planning poker isn’t tied to any framework, but most teams who use it run Scrum. For where estimation fits between backlog refinement and sprint planning, and what the Scrum Master does during a session, read the Scrum poker page.