Knowing the rules of Planning Poker takes five minutes. Running a session where every developer speaks up, disagreements surface early and the team leaves with estimates it trusts takes a facilitator.
This guide is for that facilitator, usually the Scrum Master. New to the technique itself? Start with our complete introduction to Planning Poker, then come back for the practical side: what to prepare, how to pace each round and what to do when the cards disagree.
How do you run a Planning Poker session?
To run a Planning Poker session, the Scrum Master prepares a refined backlog, agrees on one or two reference stories and picks a card scale before the meeting. Each story then follows the same round: the Product Owner presents it, the team asks questions, every developer picks a card privately, and all cards are revealed at the same time. When the estimates diverge, the people who played the highest and lowest cards explain their reasoning, and the team votes again; one to three rounds are usually enough. The facilitator keeps each discussion timeboxed, treats the ? card as a request for missing information and the coffee card as a request for a break, and ends the session before fatigue lowers the quality of the votes, typically after 60 to 90 minutes. Afterwards, the estimates go back into the backlog tool and feed sprint planning. The facilitator does not impose a number: their job is to make sure every voice is heard before the team commits.
What should a Scrum Master prepare before the session?
Most sessions that drag are lost before they start. Check four things the day before.
A backlog that is ready to estimate. Each story needs a clear description and acceptance criteria, and the Product Owner must be there to answer questions. The Scrum Guide describes refinement as breaking items down into "smaller more precise items": Planning Poker comes at the end of that work, not instead of it. Mountain Goat Software, Mike Cohn's company, also warns that waiting for sprint planning is often too late, because the Product Owner needs sizes earlier to order the backlog.
Reference stories. Without a shared point of comparison, every vote starts from scratch. Cohn recommends two references the team knows well, ideally a 2 and a 5, rather than a single 1-point story (source). Keep them visible during the whole session.
The right people. The Scrum Guide is explicit: "The Developers who will be doing the work are responsible for the sizing." Developers vote, the Product Owner explains, and managers or stakeholders join as observers: their questions are welcome, their opinion on the number is not.
A realistic scope. Pick the stories most likely to enter the next sprint or two, in priority order, so the session stays useful even if you don't reach the end of the list.
Which card scale should you choose?
Choose the scale on purpose and keep it from one session to the next.
| Scale | Values | Best for | Watch out for |
|---|---|---|---|
| Modified Fibonacci | 0.5, 1, 2, 3, 5, 8, 13, 21 | Sprint-level stories, teams using velocity | The default for a reason: the widening gaps reflect uncertainty |
| T-shirt sizes | XS, S, M, L, XL, XXL | Roadmaps, large backlogs, new teams | Sizes do not add up, so no velocity without a conversion |
| Powers of 2 | 1, 2, 4, 8, 16, 32, 64 | Teams that want starker choices | Large values hide splitting needs |
If the team hesitates between the first two, our comparison of Fibonacci vs T-shirt sizing covers the trade-offs. Whatever the scale, keep the two special cards, ? and coffee: they are signals the facilitator needs.
How do you run each round?
A round should feel the same every time, so the team focuses on the story instead of the process.
- The Product Owner presents the story. Description and acceptance criteria, read aloud or shared on screen.
- Short clarification. Developers ask about scope, dependencies and risks. If this takes more than two or three minutes, the story probably needs refinement.
- Start the vote. Everyone picks a card privately. Say nothing about the size: even "this looks small" anchors the room.
- Reveal together. All cards are shown at the same moment. In Planning Poker Online, the reveal can be triggered by the Scrum Master, by any voter, or automatically when everyone has voted.
- Read the result. Same card for everyone: record it. Neighbouring cards such as 3 and 5: a short exchange, then the team picks one. Wide spread: open the discussion.
- Record and move on. Confirm the value out loud, then present the next story.
The full rule set, with card meanings and counting conventions, is in our Planning Poker rules guide.
What should you do when estimates diverge?
Divergence is the most valuable moment of the session: people understand the story differently. Your job is to turn that into information, not to make it disappear.
Hear the extremes first. Mountain Goat Software's advice is direct: "When estimates differ, start with the high and low estimates." The person with the 13 has often spotted a risk; the person with the 3 may know a shortcut.
Never average. A 3 and a 13 do not make an 8. Averaging hides the disagreement and produces a number nobody voted for.
Vote again after the discussion. One to three rounds are usually enough, according to Mountain Goat Software. If a third round still shows a wide spread, stop: split the story or send it back to refinement with the open questions written down.
Keep your own number to yourself. Anchoring is one of the best documented biases in judgement (Tversky and Kahneman, 1974): the first number spoken pulls the others towards it. A facilitator who says "I'd have said a 5" ends the independent vote.
Divergence is normal, not a failure. On the sessions measured on our usage data page, only about a quarter of first votes are unanimous, yet most stories are settled in a single round.
How should you handle the ? and coffee cards?
The ? card means "I don't understand this well enough to estimate." Treat it as a question, not as an abstention. Ask what is missing. If the Product Owner can answer in a minute, vote again; if not, park the story with the question attached and come back to it after refinement. Forcing a number on a vague story produces an estimate nobody believes.
The coffee card is a request for a break. Take it, even if only one person played it: fatigue spreads faster than it shows. A five-minute pause costs less than half an hour of distracted votes.
Both cards are rare: together they account for less than 2% of the votes on our usage data page. When one appears, it is a deliberate signal. Planning Poker Online counts them separately, so they never distort the average or the median of the round.
How long should a Planning Poker session last?
The Scrum Guide asks the Scrum Master to make sure every Scrum event is "kept within the timebox". Planning Poker usually happens inside refinement or sprint planning, and the same discipline applies at two levels.
The session. Plan 60 to 90 minutes at most, with a short break around the 45-minute mark. Beyond that, attention drops and estimates drift. Two short sessions beat one marathon.
Each story. A countdown keeps one story from eating the meeting. As Mountain Goat Software puts it: "Timebox discussion so one item does not consume the whole session." Planning Poker Online's timer starts at 2 minutes by default, is visible to the whole team and can reveal the cards automatically when it reaches zero. When the timer runs out without agreement, either vote again or park the story; don't let the clock silently extend.
How do you facilitate Planning Poker with a remote team?
Remote sessions follow the same rules, but the facilitator must compensate for what video calls remove: body language, eye contact and the shared moment of flipping cards.
- Use a tool that keeps votes hidden until the reveal. A chat thread where people type numbers one after another brings anchoring back. Our comparison of free Planning Poker tools lists the main options.
- Share the story on screen, not only out loud, so nobody votes on a half-heard sentence.
- Ask for cameras on during discussions, and call on quiet people by name. Mountain Goat Software's remote tips ask the facilitator to "make space for quiet disagreement".
- Shorten the session. Attention fades faster on video: aim for 45 to 60 minutes.
Our guide to Planning Poker for remote teams goes further, including the asynchronous variant.
What are the most common facilitator mistakes?
- Voting as facilitator. If you are also a developer on the team, vote like the others, but never speak first after the reveal.
- Letting the Product Owner or a manager weigh in on the number. Stakeholders "should not pressure the estimate", in Mountain Goat Software's words.
- Accepting a unanimous vote without a question. Unanimity on a story nobody discussed can hide a shared blind spot.
- Converting points into days during the session. "It's a 5 because it takes five days" turns relative estimation back into time estimates; see story points vs person-days.
What should you do after the session?
Export the estimates. Planning Poker Online exports every story and its estimate as PDF or CSV, ready to copy into Jira, Linear or any backlog tool, and past sessions stay available in the history on the home page.
Follow up on parked stories. Every story set aside with a ? card needs an owner and a date, usually the next refinement.
Watch the number of rounds. If many stories need three rounds, the backlog is reaching the session too early. That is a refinement problem, not an estimation problem.
Revisit the reference stories every few months, so that estimates do not drift silently as the team learns.
Frequently asked questions
Does the Scrum Master vote in Planning Poker? Only if the Scrum Master also builds the product. The Scrum Guide gives sizing to the Developers who do the work, so a Scrum Master who only facilitates does not vote. A Scrum Master who also codes votes like any developer, but should never comment on the size before or right after the reveal.
Who should attend a Planning Poker session? A Planning Poker session needs the developers who will build the stories, the Product Owner who explains them, and a facilitator, often the Scrum Master. Managers and stakeholders can join as observers to follow the discussion and answer questions, but they do not vote and should not suggest a number to the team.
What should you do if the team cannot agree after three rounds? When a Planning Poker vote still diverges after three rounds, stop estimating that story. Write down the open questions, then either split it into smaller stories or send it back to refinement. Some teams take the higher value to keep moving, but only once everyone understands why the estimates differ.
Can you run Planning Poker without a Scrum Master? Yes. Planning Poker only needs someone to keep the pace, start each vote and protect the timebox. In teams without a Scrum Master, a developer or the Product Owner can facilitate, as long as they do not use the role to push their own estimate. Rotating the facilitator role also works well.
Sources
- Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020
- Mountain Goat Software, Planning Poker
- Mike Cohn, The Best Way to Establish a Baseline When Playing Planning Poker, Mountain Goat Software
- Amos Tversky and Daniel Kahneman, Judgment under Uncertainty: Heuristics and Biases, Science, 1974
Run your next session
Create a free Planning Poker session, share the link and run your first round in under a minute. No sign-up, no ads, and votes stay secret until the reveal. See all the features, from the shared timer to the PDF and CSV export.
