The facilitator's job is not to find the fastest number. It is to create a fair conversation in which the people doing, testing, designing, and supporting the work can expose different assumptions. This playbook is intentionally tool-agnostic: use it with a physical deck or with the Simple Plan Poker room.
Before the session: make the item estimable
Planning poker cannot repair an item that has no shared outcome. Before inviting the team, write one sentence describing who needs what and why. Add the acceptance conditions that change the size of the work, and name the boundaries that are explicitly out of scope. This prevents the vote from becoming a design meeting with no decision.
- Identify the user or system that benefits from the change.
- List acceptance conditions, including error paths and operational work.
- Call out dependencies, migrations, permissions, integrations, and unknown technology.
- Choose one reference item that the team has already completed.
- Split the item if it contains unrelated outcomes or more than one release-sized risk.
Send the item and its context before the meeting when possible. Participants do not need to prepare a number; they do need enough time to notice questions. A short pre-read produces a better discussion than using the first ten minutes to discover the title is ambiguous.
Open the meeting with a working agreement
A two-minute agreement protects the quality of every later vote. Explain that points are relative, not promises of hours, and that the purpose is shared understanding. Ask participants to vote independently and to use the question card when they cannot estimate honestly. Agree that a wide spread is a reason to learn, not a reason to punish the person who chose the largest number.
“We are estimating the work as we understand it today. We will reveal together, listen for different assumptions, and record an open question instead of pretending uncertainty is precision.”
Use the same rhythm for every item
- Frame the outcome. Read the item, acceptance conditions, and the boundary of the discussion.
- Invite questions. Capture questions that need product, design, security, or technical follow-up.
- Choose a reference. Name a completed item that provides a shared sense of size.
- Vote privately. Give everyone a quiet moment to choose a card, including ? if needed.
- Reveal together. Look first at the spread, not at who chose which number.
- Hear the edges. Ask the highest and lowest voters to explain what their estimate includes.
- Resolve or record. Clarify the assumption, split the item, or record an owner and a follow-up date.
- Vote again. Stop when the team has enough shared confidence to plan the next step.
Prompts for a wide spread
A spread from 3 to 13 is not an invitation to average the cards. It usually means that the voters are estimating different work. Keep the conversation concrete with prompts such as these:
- “What is included in your estimate that another person may not have included?”
- “Which assumption would make this item twice as large?”
- “Are we discussing implementation effort, uncertainty, or both?”
- “Is there an existing component, pattern, or reference item we can compare with?”
- “What would we need to learn before this becomes a smaller, safer slice?”
After the discussion, state the new shared assumption out loud. For example: “The first release uses the existing identity provider; a new provider is a separate follow-up.” Only then ask for another vote. If the spread remains wide, keep the uncertainty visible and create a discovery task rather than forcing consensus.
When to stop the discussion
Facilitation becomes costly when every disagreement turns into an endless design debate. Stop and create a follow-up when the group is repeating the same arguments, when the answer depends on an experiment, or when the item is too large to make meaningful in one vote. A useful stopping rule is: one clarification, one re-vote, then an explicit decision to estimate, split, or investigate.
Record the decision in the backlog. Include the agreed estimate, the reference item, the assumptions that made the number possible, and any unanswered question. This note is more valuable than the number alone because it explains when the estimate should be revisited.
Five-minute session worksheet
| Prompt | Notes |
|---|---|
| Desired outcome | Who benefits, and what changes when this is done? |
| Acceptance boundary | What is included, excluded, and required for “done”? |
| Reference item | Which completed item anchors the team’s shared scale? |
| Vote spread | Lowest, highest, and the assumption behind each edge. |
| Decision | Estimate, split, investigate, or defer—with an owner. |
| Revisit trigger | What new information would change this estimate? |
After the session: improve the system, not individual estimates
Review the pattern of conversations after a few sessions. Repeated high votes may indicate an architectural or operational bottleneck. Repeated question cards may indicate missing product context. Estimates that change after implementation are not evidence that a person failed; they are evidence that the team learned something. Use that learning to improve slicing, discovery, and the reference items used in future sessions.
For the core workflow, continue with the planning poker guide. For a complete example of a divided vote, read the worked estimation example, then browse the resource library for remote-session and story-splitting guidance.