Planning poker rules are a simple yet powerful set of practices teams use to produce faster, more reliable estimates for software work. Built on relative estimation and team consensus, planning poker helps surface assumptions, reduce anchoring bias, and increase shared understanding of scope. Below I explain the rules step‑by‑step, share lessons learned from facilitating dozens of estimation sessions, and provide practical variations you can use today — including examples that make the process feel natural for both co‑located and remote teams.
Why use planning poker?
At its core, planning poker turns estimation into a collaborative conversation instead of a single person's guess. It addresses two common problems:
- Anchoring bias: When one person's early number skews the rest of the team.
- Hidden assumptions: When different team members interpret requirements in different ways.
By following the planning poker rules, teams surface differences, force brief discussions about tradeoffs, and converge on a number that represents the team's shared understanding. It is not a tool for micro‑management, but for creating a reliable baseline for sprint planning, backlog grooming, and capacity forecasting.
Core planning poker rules (step‑by‑step)
Below is a practical sequence that I follow when facilitating planning poker. Every step reflects a rule you can adopt immediately.
- Prepare the backlog items. The product owner or proxy presents a single story, feature, or task with acceptance criteria and clarifying notes. Keep items short and well defined.
- Set roles and timebox the discussion. One person facilitates (keeps time and enforces rules). Each discussion should be brief — typically 3–8 minutes before voting.
- Choose a card scale. Use a Fibonacci‑like series (1, 2, 3, 5, 8, 13, 20, 40, 100) or modified exponential cards. The exact labels matter less than the concept of diminishing precision for larger items.
- Silent first vote. After clarifying questions, each estimator privately selects a card representing their estimate. No discussion until everyone has chosen.
- Reveal simultaneously. All cards are revealed at the same time to avoid anchoring. For remote teams use a digital planning poker tool or show cards on camera.
- Discuss divergent votes. If estimates differ, ask the highest and lowest voters to explain their reasoning. Keep these explanations focused and timeboxed.
- Re‑vote until consensus. Conduct additional rounds until estimates converge or the team agrees to take the median/average. Avoid endless debate — aim for a pragmatic agreement.
- Record and move on. Capture the agreed estimate, any assumptions, and open questions. Then continue to the next backlog item.
Roles and responsibilities
- Product Owner: Explains the story, acceptance criteria, and business context.
- Team Members (Estimators): Developers, QA, UX — those responsible for delivery. Everyone on the team votes.
- Facilitator/Scrum Master: Keeps time, enforces the rules, prevents side conversations, and ensures the process is productive.
Choosing the right card set
The most popular scales are Fibonacci and modified powers of two. Why Fibonacci? It mirrors the increasing uncertainty of larger items — the difference between 1 and 2 is meaningful, while the difference between 20 and 21 is not. Many teams also add a “?” card for unclear stories and a “coffee” or “break” card to signal interruptions.
Handling common situations
When one person dominates:
Enforce the silent first vote and simultaneous reveal. If dominance persists, the facilitator should invite quieter members to explain their views first during the discussion phase.
When estimates don’t converge:
Break big items into smaller ones. If convergence fails after two or three rounds, the item likely needs more refinement — mark it for further backlog grooming.
When technical debt or non‑functional work must be estimated:
Use the same rules but include cross‑functional team members (operations, security, QA) so all perspectives are considered. Explicitly capture non‑functional acceptance criteria before voting.
Example session: a real‑world walkthrough
During a recent planning session I facilitated for a team building a customer portal, a story labeled “Implement password reset flow” triggered widely divergent numbers: votes were 2, 3, 13, 8. The 13 came from a developer concerned about integration with an external authentication provider; the 2 and 3 came from UX and QA who assumed a simple in‑app flow. By asking the high voter to explain, we discovered a missing requirement: support for external identity providers. We split the story into “basic in‑app reset” (3) and “external provider integration” (13). The team finished faster because assumptions were clarified and risk isolated.
Advanced tips and variations
- Use a “relative baseline” story: Keep a reference story with a known size. Compare new items to that baseline to improve consistency.
- Limit estimators: For very large teams, use a representative subgroup to estimate and then review with the entire team to reduce noise.
- Asynchronous estimation: For distributed teams across time zones, use tools that allow asynchronous card reveals followed by a synchronous or asynchronous discussion.
- Estimate in two dimensions: For complex work, estimate effort and risk separately to prioritize what needs technical spikes first.
Measuring success and avoiding anti‑patterns
Planning poker is not about perfect precision. Success metrics include:
- Reduced rework from misunderstood requirements
- Shorter planning meetings over time as the team gains a common estimation language
- More predictable velocity with fewer missed commitments
Anti‑patterns to avoid: using estimates as promises to stakeholders without accounting for uncertainty, allowing a single voice to dictate estimates, or skipping discussion and treating planning poker as a bureaucratic exercise.
Tools and remote facilitation
Several digital tools replicate planning poker cards and simultaneous reveal, but the rules are the same. When working remotely:
- Ensure good audio/video so everyone can participate.
- Use breakout rooms if the number of stories or team size makes synchronous discussion unwieldy.
- Stick to short timeboxes and a clear facilitator role to maintain momentum.
When to skip planning poker
Not every backlog item needs an elaborate estimation. Skip detailed planning poker for trivial, well‑understood tasks or when a story is too small to matter — use a simple bucket (T-shirt sizes or binary “small/medium/large”) and move on.
Final checklist: quick planning poker rules summary
- Present one item at a time with clear acceptance criteria.
- Ask clarifying questions, then vote privately.
- Reveal simultaneously and discuss disagreements briefly.
- Re‑vote until consensus or practical agreement is reached.
- Record the estimate, assumptions, and outstanding risks.
Where to learn more
To expand your team's practice, experiment with the variations above, keep a reference story library, and periodically review how estimates track to actuals. For additional tools and community examples, visit keywords for general resources and inspiration. If you want a hands‑on workshop template or a facilitator checklist, check keywords to download materials and sample agendas.
Planning poker rules are deceptively simple: when applied with discipline and empathy they turn estimation into a learning ritual that improves both planning accuracy and team alignment. Start small, reflect on outcomes, and adapt the rules to your team's context — the real value is the conversation that the rules enable.
