How to Use Planning Poker
Planning poker works best when the team follows a simple, repeatable flow. This step-by-step guide shows how to run a productive estimation session and reach consensus faster.
How to use planning poker step by step
- Gather your team and open the backlog item you want to estimate.
- Explain the task and review acceptance criteria, dependencies, and risks.
- Each member selects a card privately using your team's story point scale.
- Reveal votes simultaneously to reduce anchoring and groupthink.
- Discuss differences, especially the highest and lowest estimates.
- Repeat if needed until the team reaches a stable estimate.
Tips for better planning poker sessions
- Keep stories small: very large stories are hard to estimate well.
- Use reference stories: compare new work to items the team already understands.
- Timebox the discussion: avoid turning one estimate into a long debate.
- Capture unknowns: if something is unclear, add a spike or split the story.
Agile estimation techniques that pair well with planning poker
Planning poker is one of the most practical agile estimation techniques for cross-functional teams. You can also combine it with reference stories and velocity review to keep estimates consistent sprint over sprint.
When to use planning poker vs. t-shirt sizing
Use t-shirt sizing for early discovery, then switch to planning poker when stories are refined enough for sprint commitment. Learn story point estimation.
Sprint planning poker example flow
During Sprint Planning, pull one backlog item, vote privately, reveal together, discuss outliers, and re-vote. Repeat until the team can confidently include the story in the Sprint goal. For the full context, read our Scrum planning guide.
Preparing for a planning poker session
A planning poker session is only as good as the preparation that precedes it. Teams that enter planning poker with unrefined stories, missing acceptance criteria, or unclear dependencies waste most of their session on clarification rather than estimation. The goal of preparation is to ensure the team can vote within 30 seconds of reading each story.
Choosing which backlog items to estimate
- Select items scheduled for the next 1–2 sprints: estimating stories too far in advance is often wasted effort — the scope will change.
- Check acceptance criteria exist: a story without acceptance criteria cannot be estimated reliably. If criteria are missing, add a refinement task instead of estimating the story.
- Flag dependencies upfront: if a story depends on another team's output or an unresolved technical decision, mark it as blocked before the session so the team doesn't spend time on a story that cannot move forward.
Setting up the estimation tool
- Create the session before the meeting: copying story titles into the tool during the meeting costs focus and momentum. Set up the session list at least 30 minutes beforehand.
- Choose the right scale: confirm the team's preferred scale (Fibonacci is standard). Changing scales mid-session creates confusion about whether estimates are comparable.
- Test the reveal mechanism: ensure everyone can see the same cards and that votes are hidden until the facilitator reveals. Nothing disrupts the session faster than a participant accidentally seeing others' votes before the reveal.
What to do when planning poker votes diverge
Vote divergence is not a problem — it is the most valuable output of planning poker. When one person votes 2 and another votes 13, they are not making an estimation error. They are revealing that the team has fundamentally different mental models of what the story involves. Resolving that difference is worth every minute of discussion.
Handling extreme outliers
Ask the highest voter to speak first. They almost always know about a risk, a dependency, or a technical constraint that others missed. This prevents the discussion from anchoring on the low vote.
Ask the lowest voter second. Low votes often come from someone who has done similar work before and knows a shortcut, or from someone who has misunderstood the scope. Both are useful to hear.
Deciding how many rounds to run
Most stories reach consensus within two rounds. If the team is still split after three rounds, the story is not ready — it needs more refinement. Record the unresolved estimate, add clarification tasks to the backlog, and move on. Do not force consensus through fatigue.
A common anti-pattern is "splitting the difference" — if votes are 5 and 8, rounding to 7. This produces a number that nobody believes in. It is better to re-vote after a brief discussion and let the team converge naturally.
If a single story is consuming more than 10 minutes of discussion, call a timeout. Note the specific open question, assign it as an action item, and proceed with a placeholder estimate. Refinement, not planning poker, is the right venue for deep architectural discussions.
Planning poker facilitation tips for Scrum Masters
The Scrum Master's job during planning poker is not to estimate — it is to protect the process. A well-facilitated planning poker session keeps energy high, prevents anchoring, and ends on time. A poorly facilitated one devolves into a debate club where the loudest voice wins.
Keeping the session moving
- Set a visible timer: display a countdown for each story's discussion phase. Visible timers reduce the tendency for discussions to expand to fill available time.
- Batch simple stories: for stories that are nearly identical (for example, five similar API endpoints), vote on one as a benchmark and offer the team a quick confirmation vote on the others before discussing each individually.
Managing long debates
- Name the blocker explicitly: when a discussion stalls, articulate what question is preventing consensus. "It sounds like we're uncertain whether this requires a database migration. Let's note that and re-vote assuming it does." Named blockers are easier to resolve than vague disagreement.
- Separate estimation from design: planning poker should estimate work that is understood, not design work that isn't. If the team is debating architecture during estimation, the story needs a technical spike — not a story point number.
After the session, the Scrum Master should review the velocity trend and flag any stories whose estimates feel like outliers compared to historical similar work. Consistent over-estimation of certain story types is a signal worth raising in the next retrospective.
Related planning poker resources
Planning poker FAQ
How long should planning poker take for one story?
For a well-refined story, one round usually takes 1 to 3 minutes. If a discussion runs long, split the story or capture unknowns and move on.
Can we run planning poker during Sprint Planning?
Yes. Many teams run sprint planning poker when estimates are missing or when story scope changed after refinement.
Which story point scale is best?
A Fibonacci scale (1, 2, 3, 5, 8, 13, 21) is the most common because it reflects growing uncertainty for larger work items.
Should we estimate bugs in story points?
Many teams estimate bugs the same way as features, especially for significant ones with unclear scope. Small, well-understood bugs (under 2 hours) are often tracked separately without story points to avoid inflating the velocity count with trivial work.
What if a team member always votes lower (or higher) than everyone else?
Consistent outlier voting is usually informative, not problematic. A developer who always votes low may have architectural knowledge that reduces complexity for them. A developer who always votes high may be including testing and documentation that others forget. Use it as a conversation starter, not a correction.
How do we handle "I don't know" or missing information during a vote?
Most planning poker tools include a question mark or coffee cup card for this. When a team member selects it, pause the vote and address their question before re-voting. Never estimate through acknowledged ignorance — it produces numbers the team doesn't believe in.