Facilitator guide for planning poker sessions

What the facilitator owns

The facilitator owns the process, not the estimate. Their job is to protect private voting, keep the room focused, invite quiet voices, surface assumptions behind outliers, and close each story with a clear decision. They should not push the team toward a lower number or let a stakeholder override the people doing the work.

A strong facilitator watches for signals: repeated high spreads, confusion about acceptance criteria, one person dominating discussion, or stories that repeatedly land at the top of the deck. SprintDeck helps by showing progress and reveal results, but the facilitator still decides when the team needs clarification, splitting, or a final estimate.

A reliable facilitation pattern

The safest planning poker sessions follow a small repeatable loop: clarify the story, confirm acceptance criteria, give everyone a quiet moment to think, vote privately, reveal at the same time, and discuss only the spread that matters. That loop keeps the meeting from becoming a loud negotiation and gives quieter team members the same chance to influence the estimate as the first person who speaks.

SprintDeck is designed around that loop. A facilitator can create a room, share a code, choose a deck, watch voting progress, reveal once enough people have voted, and capture the final estimate while the conversation is still fresh. The tool does not replace product thinking or technical judgment; it protects those judgments from anchoring, scattered notes, and manual coordination overhead.

• Keep the story small enough that the team can reason about risk without inventing hidden scope.
• Ask for questions before voting, but avoid discussing numbers before the reveal.
• Treat a wide spread as useful information, not as failure.
• Capture the final estimate and the reason for any large disagreement before moving to the next item.

Common mistakes to avoid

The most common failure is turning estimation into a debate before independent votes exist. When a tech lead or product owner suggests a number early, the rest of the room often adjusts around that anchor. Another failure is forcing the average after reveal. An average can summarize numbers, but it cannot explain uncertainty, missing acceptance criteria, or a disagreement about architecture.

A healthier session makes disagreements visible and then narrows them deliberately. If estimates are close, the facilitator can confirm whether the group accepts the mode or median. If estimates are far apart, ask the highest and lowest voters what assumption drove their number. The goal is not to make every card identical; the goal is to uncover risk while the team can still respond.

• Do not reveal votes one by one.
• Do not use planning poker to pressure teams into lower commitments.
• Do not estimate vague stories just to keep the meeting moving.
• Do not treat story points as hours with a different label.

Facilitator interventions that help

A facilitator should intervene when someone states a number before private voting, when one person dominates the explanation, when the team debates implementation details that do not affect the estimate, or when a stakeholder pressures the group toward a lower value. The intervention should protect the process, not embarrass the participant.

Use neutral prompts: 'Let's vote before discussing numbers,' 'What assumption made that card higher?', 'What would need to be true for this to be smaller?', and 'Should this story go back to refinement?' These prompts turn disagreement into actionable information.

• Protect private voting.
• Invite quieter participants after reveal.
• Ask for assumptions, not just numbers.
• Return unclear work to refinement.

What to capture after the estimate

Capture the final number and the reason the team accepted it. If a story moved from 13 to 8 because scope was clarified, write that down. If it stayed high because operational risk remains, write that down too. The note helps future reviewers understand that the estimate came from reasoning, not ceremony.

A facilitator who consistently captures reasons builds trust. Product Owners see why work is sized a certain way, developers see that risk was heard, and future planning sessions can reuse the team's own examples.