Planning poker facilitation: 12 tips for faster, fairer estimates

Good planning poker facilitation comes down to two jobs: protecting the private vote, so every first estimate is independent, and spending discussion time only where the cards disagree. Do both well and sessions become faster and fairer at once, because quick items take seconds and the hard ones get the attention they deserve.

The 12 tips below are grouped by the moment in a session when they matter. They are written for new facilitators, but they are just as useful for experienced teams whose sessions have drifted into bad habits: sizes said out loud, averages instead of conversations, the same voices every time. If you need the basic sequence first, see how to run a planning poker session.

Before the vote

1. Prepare the items and the references, not just the meeting

Half of facilitation happens before anyone picks a card. Check with the product owner that each item has a goal and acceptance criteria, drop anything that does not, and put two or three reference stories where everyone can see them. A team asking “is this bigger than the reorder feature?” estimates faster and more consistently than one staring at a blank scale. Choosing reference stories explains how to pick them.

2. Keep numbers out of the room until the reveal

Anchoring is the bias planning poker exists to beat, and it creeps back in through casual remarks: “should be quick”, “it’s basically a 2”, “last time this took a day”. Each one pulls the votes that follow towards it, even when people try to ignore it. Make it a team rule that sizes are only spoken after the reveal, and enforce it lightly: “Hold that thought until we flip.”

3. Keep the product owner out of the vote

The product owner’s job in a round is to explain the item, answer questions and make scope trade-offs. The Scrum Guide gives sizing to the people doing the work: “The Developers who will be doing the work are responsible for the sizing.” A product owner who votes, or who winces at a big number, pulls the estimate towards what they hope for. The same goes for managers: welcome them as observers, not voters.

Reading the reveal

4. Let the outliers speak first

When the cards spread, ask the highest and lowest voters to explain before anyone else talks. They usually hold the information the rest of the team lacks: the high card has spotted a risk or hidden work, the low card knows a shortcut or an existing component. Ask about the work, not the number. “What were you picturing?” invites an answer; “Why so high?” puts people on the defensive.

5. Treat the ? card as a signal

A ? is an honest vote: “I can’t size this with what I know.” Respond with a question, not a nudge: “What would you need to know?” If one person plays it, the answer may take a minute to find. If several do, the item is not ready, and the right move is to take it out of the round and find the missing information rather than push people into guessing.

6. Ask for the whole job, not just the code

A common cause of a wide spread is people estimating different scopes. The developer pictures the code change; the tester pictures the regression run, the test data and the edge cases; the designer pictures the empty states and error messages. Before voting, remind the team to size everything your Definition of Done requires: code, tests, review, documentation and release. Many “surprising” high cards turn out to be the most complete estimate in the room.

Keeping rounds short

7. Timebox every discussion

Set a limit for the discussion after each reveal (two minutes is a good start) and let anyone call time. When it runs out, vote again. A timer stops the occasional fascinating debate from eating the session, and a visible countdown works better than a facilitator interrupting, because nobody takes a timer personally.

8. Converge, don’t average

Averaging feels fair and quick, but it throws away the reason for the discussion. If the votes are 3, 3, 5 and 13, the mean of 6 is a number nobody chose, and the 13 may be warning you about something real. Talk, re-vote and, if you are stuck between two neighbouring values, ask: “Can everyone support a 5?” Mike Cohn suggests that a team which truly must average should use the median rather than the mean.

Don’t force agreement either. The Agile Alliance glossary warns against making convergence an obligation, because a wide spread is itself useful information about how uncertain an item is. Sometimes the right outcome is the higher number with the risk written next to it.

9. Split big items instead of estimating them

Large estimates carry the most uncertainty, and long debates often mean an item is really two or three items. Agree a ceiling, for example that nothing above 13 enters a sprint, and when the cards land above it, stop estimating and start splitting. Splitting by workflow step, business rule or type of data usually works; how to split user stories has the patterns.

10. Park design debates

Estimating needs enough understanding to size the work, not a finished design. When two developers start debating which library to use, ask one question: “Does the choice change the size?” If not, vote. If it does, either size the bigger option and note the assumption, or create a short spike to decide and bring the item back next time.

Energy and remote etiquette

11. Manage the room’s energy

As a session wears on, discussions shorten, outliers stop speaking up and the team starts agreeing with whatever ends the meeting soonest. Keep sessions to an hour or less, put a break in anything longer, and take the coffee card seriously when someone plays it. Order matters too: among the items you need for the next sprint, take the ones that need the most thought early, while people are fresh, and finish with quick ones.

12. Set remote etiquette

Remote rounds need a few explicit agreements that teams in a room get for free:

• Read each item aloud and share it on screen, so nobody votes on a title alone.
• Turn cameras on for the discussion if the team is comfortable with it; hesitation and reactions are part of the conversation.
• Use a raised hand or the chat to queue, so quieter people get a turn.
• In hybrid sessions, everyone votes in the same online tool, including people sitting together.
• No voting while doing something else. If you are on a train or in another meeting, abstain.

For teams spread across time zones, an async round before the meeting lets everyone vote with a comment, so the live session only covers the items where votes disagree. Remote planning poker covers distributed teams in more depth.

For experienced teams: check your calibration

Teams that have estimated together for a year or more rarely struggle with the mechanics. Their risk is drift: estimates that slowly inflate, reference stories nobody remembers, and confidence that is no longer earned. A few habits keep a mature team honest:

• Review a few finished items each sprint. In the retrospective, pick two or three completed items and ask: “Knowing what we know now, would we still call this a 5?” You are checking relative size, not the hours it took.
• Refresh your reference stories. Every few months, replace references the team no longer remembers with recent, well-understood items.
• Record the spread, not just the number. An 8 everyone agreed on and an 8 that started as anything from 3 to 20 are different risks. Noting the first-round range next to the estimate tells the product owner which items might surprise you, and shows patterns worth discussing in retrospectives.
• Talk in ranges for risky items. Before voting on something with a big unknown, ask for the best and worst case. If the worst case is several times the best, the item probably needs a spike or a split, whatever card the team plays.
• Make dependencies visible. Do not quietly pad an estimate because another team might be late. Record the dependency on the item, where the product owner can see and manage it.
• Watch for reveals that never disagree. If every reveal shows the same card, check that numbers are not leaking before the vote and that people are not simply following a senior colleague.

A facilitator’s cheat sheet

Keep these phrases to hand for the moments that come up in almost every session.

On planningpoker.org The SprintPoker room has a round timer for timeboxing discussion, and every deck includes a ? card that counts as a vote but never towards the average. With a free Laya account, in sessions on a Laya board or a Jira board, Reference Issues and Matching Issues show items your team has estimated before, so a new item can be compared with sizes the team has already agreed.