Planning poker facilitation guide
Planning poker facilitation is the Scrum Master's highest-leverage contribution to estimation quality. A well-facilitated session surfaces hidden knowledge, converges on consensus, and finishes on time. A poorly facilitated session degrades into social negotiation, produces numbers the team doesn't believe in, and takes twice as long. This guide covers the role, the rules, and the real-world problems every facilitator eventually encounters.
The facilitator's role in planning poker
The facilitator's job is to protect the process — not to estimate, not to push toward a particular number, and not to resolve technical debates. The facilitator's job ends when the team has agreed on an estimate.
- Before the session: load the stories, confirm all participants are in the tool, verify the scale is correct, and review the story list to flag any items that might need splitting.
- During each round: read the story, allow clarifying questions (factual only), trigger the vote, reveal cards simultaneously, call on extreme voters to explain first, and timebox the discussion.
- Between rounds: record accepted estimates, note any unresolved questions, and keep energy high. The facilitator's tone sets the session's pace.
- After the session: share the estimates with the team's tracking tool, record any action items (stories needing splitting, clarification tasks), and note any patterns worth raising in the retrospective.
The non-negotiable facilitation rules
These rules exist for specific statistical reasons. Skipping them degrades estimate quality in documented, measurable ways.
- No complexity discussion before the reveal: any pre-reveal opinion about size anchors other voters. This is the highest-impact rule.
- Simultaneous reveal only: if someone reveals early (even accidentally), re-vote the story. The reveal mechanism is the point.
- Extreme voters speak first: ask the highest voter, then the lowest voter. Then allow general discussion. This order surfaces the most valuable information first and prevents the group from anchoring on a middle-range opinion.
- Maximum three voting rounds per story: after three rounds without convergence, the story is not ready to estimate. Record it as deferred, add a clarification task, and move on.
- Every participant votes: observers (stakeholders, Product Owner in some team setups) do not vote. Every development team member does. No exceptions.
Real-world facilitation challenges
Even with clear rules, experienced facilitators regularly encounter situations that require judgment rather than procedure.
The dominant personality problem
Some teams have one or two people whose technical opinions carry more weight than others. When these people share their complexity assessment before the reveal, other team members adjust toward them — even if their own analysis says something different.
Fix: implement a strict no-discussion-before-reveal rule and enforce it consistently. When the dominant personality speaks before the reveal, gently interrupt: "Let's get everyone's vote first, then we'll hear everyone's reasoning."
Technical rabbit holes
Planning poker discussions sometimes become impromptu architecture discussions. Two or three people start debating implementation approaches while the other five wait. The debate is valuable — but not during estimation.
Fix: name the rabbit hole explicitly. "This sounds like a design question rather than an estimation question. Let's note it as a spike and estimate based on the most likely approach." Then re-vote.
New team members
New team members either under-vote (deferring to perceived expertise) or over-vote (overcompensating to seem capable). Both patterns reduce estimate quality.
Fix: before the first session, walk the new team member through two or three reference stories. Explain that there is no correct answer and that their input is genuinely valuable. After the session, briefly discuss any votes where they were an extreme outlier — not to correct them, but to calibrate their mental model.
Facilitating async planning poker sessions
Async facilitation requires the same discipline as synchronous, applied differently. The facilitator cannot intervene in real-time, so the instructions and structure must be more explicit.
- Write full story context in the tool before opening the voting window — links to acceptance criteria, screenshots, design mocks, anything relevant.
- Set a clear voting window (24 hours is standard) and communicate the close time explicitly in all time zones.
- After the window closes, review all votes before sharing results. Flag any votes that require follow-up explanation and prepare targeted questions for extreme voters.
- Share the results with a brief written summary: consensus stories, divergent stories, and action items. This replaces the verbal session close.
Facilitation FAQ
Does the facilitator estimate?
The Scrum Master as facilitator typically does not vote in the first round to avoid anchoring the team. If the Scrum Master is also a developer who will work on the stories, they can vote — but should be especially disciplined about not sharing their estimate before the reveal.
What happens when the Product Owner wants to influence estimates?
The Product Owner can clarify scope but should not influence complexity estimates. If a PO says "this should only be a 3" before the reveal, gently redirect: "We'll vote first on complexity, then the PO can weigh in on priority." Estimate calibration is the development team's domain.
How do we handle a team member who always votes "I don't know"?
First, identify why. Is the story unclear? Is the team member unfamiliar with the codebase area? Is there a psychological safety issue with voting and being wrong? Address the root cause rather than the symptom. A "?" vote is valid information — it means the story needs more clarity before it can be estimated.
Should we use a timer for each story?
Yes. A visible timer (typically 2–3 minutes for the discussion phase) reduces the tendency for discussions to expand indefinitely. Knowing the timer is running creates a natural urgency to surface the most important point first.
Run your next planning poker session free — built for Scrum teams