Scrum poker is a deceptively simple ritual that transforms vague guesses into meaningful team commitments. In my decade of working with product teams as a delivery lead and Agile coach, I’ve seen planning sessions that move projects forward—and ones that grind to a halt—based almost entirely on how estimation is run. This article synthesizes practical techniques, pitfalls to avoid, remote adaptations, and real-world examples so your next estimation session actually improves planning, predictability, and team alignment.
What is scrum poker and why it matters
At its core, scrum poker (also known as planning poker) is a collaborative estimation technique where team members simultaneously reveal relative estimates for backlog items to avoid anchoring and to surface differences in understanding. Each estimate is typically a number from a sequence (Fibonacci, modified Fibonacci, or powers of two), or a sizing scale such as T-shirt sizes. The value isn’t the number itself; it’s the conversation the numbers provoke.
Why does it matter? Because good estimates help with forecasting, sprint commitment, and stakeholder trust. Teams that regularly practice disciplined estimation tend to have steadier velocity and fewer surprises. Done poorly, estimation wastes time and creates illusionary certainty—often because a single dominant voice anchors the discussion, or because the team substitutes optimism for analysis.
How scrum poker works — step by step
Here’s a practical sequence to run an effective session. You can perform these steps in-person with physical cards or remotely using a digital tool. I’ve used both approaches and will share tips for each.
- Prepare the backlog: The product owner or backlog manager ensures items are well-written and prioritized before the session.
- Clarify scope: Read the user story aloud and confirm acceptance criteria. If anyone is unclear, discuss until the story’s intent is understood.
- Silent estimation: Each participant privately selects a card (or clicks a number) representing their estimate—this prevents early anchoring.
- Reveal simultaneously: Everyone shows estimates at the same time.
- Discuss outliers: Ask those with the highest and lowest estimates to explain their reasoning. Often misalignment stems from differing assumptions.
- Revote if needed: After clarifying, vote again. Convergence typically occurs within a round or two.
- Record and move on: Save the agreed estimate and proceed to the next item. Keep discussions time-boxed to avoid analysis paralysis.
Choosing an estimation scale
The choice of scale influences clarity and speed. Here are commonly used options and when to use them:
- Fibonacci (1, 2, 3, 5, 8, 13…): Encourages recognising growing uncertainty for larger items. Good default.
- Modified Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100): Helpful for very large items where finer granularity isn’t useful.
- T-shirt sizes (S, M, L, XL): Useful for early-stage product discovery or when precision isn’t needed.
- Dot/vote-style or binary (0/1): For very small tasks or when you only need to know “small vs large.”
My teams often start with Fibonacci for development work and use T-shirt sizes during discovery. The important part is consistency and ensuring the team agrees on what each value represents in terms of expected effort and risk.
Common problems and how to solve them
Scrum poker sessions can go sideways. Below are recurring problems I’ve encountered and practical fixes that work in real teams.
Problem: Anchoring bias
When one person suggests a number first, others tend to gravitate to it. The simultaneous reveal solves this, but facilitation matters. If one person dominates the discussion after reveals, explicitly ask quieter members for their perspective. Rotate the facilitator periodically to prevent single-person control.
Problem: Endless debate
Time-box each item. If a discussion isn’t resolving in the first two rounds of votes, park the item for deeper analysis (spike or research task) and move on. Establish a rule that items needing more than X minutes will be split or investigated separately.
Problem: Too much precision
Teams sometimes fight over single-point differences. Remind everyone that an estimate is a forecasting tool, not a contract. Use broader buckets for large items and split large stories into smaller, independently valuable pieces.
Problem: Mixing complexity and size
People can conflate technical complexity, unknowns, and effort. Encourage the team to call out risk explicitly during discussion. If risk drives an estimate, add a note or create a spike to reduce uncertainty before committing.
Remote scrum poker — tools and best practices
Remote work made digital scrum poker tools essential. I’ve coached distributed teams across time zones and seen what works: tools that integrate with your workflow (Jira, Azure DevOps, Trello) and low-friction interfaces (Miro, MURAL, or dedicated planning poker apps).
For remote sessions, consider these practices:
- Use a lightweight video call: Seeing faces helps. Keep cameras on when possible to capture non-verbal cues.
- Share the backlog item in the chat: Paste the story and acceptance criteria into the meeting chat or the estimation tool to ensure everyone sees the same text.
- Time-zone friendly scheduling: Break sessions into shorter slots and distribute items across multiple days if necessary.
- Use integrated cards: Dedicated planning poker apps often support simultaneous reveal and automatic logging. If you prefer a manual approach, digital whiteboards with voting plugins are effective.
If you want a quick online example when testing a new team, try inviting them to a one-page remote session and use a free planning poker tool—the format and flow matter far more than the particular app. For teams curious about an unconventional pairing of a familiar card-game metaphor with formal estimation, check this link: scrum poker. It’s an unlikely but memorable way to introduce cards into your routine and explain mechanics to stakeholders unfamiliar with Agile rituals.
Advanced techniques and scaling
When teams grow or projects become complex, simple tweaks can keep estimation effective.
Relative sizing across teams
When multiple teams estimate the same product, create a shared baseline: pick a canonical story that every team understands and assign it a reference value. This helps translate individual team velocities into cross-team forecasts.
Using historical data
Don’t ignore data: map past estimates to actuals to refine what a “5” or an “8” means for your team. If you track outcomes for several sprints, patterns will emerge—certain story types consistently overrun, others finish faster. Use that insight to recalibrate and to guide decomposition of risky stories.
Dealing with non-development work
Design, research, and Ops tasks often require different thinking. Use separate estimation sessions or scales for these types of work to avoid distorting development velocity.
Measuring the value of estimation
Estimation isn’t valuable for its own sake. Measure whether it actually improves outcomes. Useful measures include:
- Forecast accuracy over several sprints (how often did planned work reach done?)
- Reduction in scope creep within sprints
- Time spent in refinement per story versus post-sprint rework
- Team satisfaction with planning and predictability (pulse surveys)
These metrics help you decide when to tighten or loosen estimation rigour. If your forecasting accuracy isn’t improving, change tactics: split stories, do more discovery spikes, or adjust your estimation scale.
Real-world anecdote: A session that saved a release
In one memorable engagement I coached, a team was three weeks from a hard release date and estimates looked optimistic. During a planning poker session, a junior QA engineer voted much higher than developers for several stories due to concerns about flaky dependencies and environment setup. The developers initially dismissed the concerns, but after the QA engineer described the instability and walked through a recent failure, the team created a spike to stabilize the environment and re-sized several items. That single conversation—brought to light by the voting spread—prevented a late release scramble and improved test reliability for subsequent sprints. It’s an example of how the method surfaces hidden domain knowledge that would have otherwise remained siloed.
When to skip scrum poker
Not every backlog item needs a full planning poker round. Skip or expedite estimation for:
- Trivial tasks that are consistently small and predictable.
- Well-understood repeatable work that can use a standard template estimate.
- Items clearly identified as spikes or research—estimate them as time-boxed investigations instead of detailed story points.
The pragmatic use of estimation time is part of maturity—don’t treat planning poker as a ritual you must run for every single card.
Practical tips to improve your next session
- Limit participants to those with direct knowledge and decision authority; invite others as subject-matter consultants.
- Rotate who explains the story aloud to keep perspectives varied and avoid "PO monotony."
- Maintain a visible parking-lot for complicated items that need spikes.
- Celebrate small wins: closing a difficult estimation quickly or reducing average discussion time is progress.
- Document assumptions made during estimation in the story to avoid later surprises.
Conclusion — making scrum poker productive for your team
Scrum poker is more than a card game; it’s a facilitation technique that turns hidden assumptions into productive conversations. With a consistent scale, good facilitation, and attention to data, teams can transform chaotic planning into predictable delivery. Start small, record what you learn, and iterate: if an item consistently derails estimates, treat it as a learning opportunity and change your approach. For teams experimenting with analogies and tangible cards to teach the ritual, a surprising example can sometimes make the concept stick—try this playful link when introducing the idea: scrum poker.
If you’d like a checklist or a printable planning session agenda tailored to your team size and cadence, tell me your team context (size, remote vs co-located, toolchain) and I’ll draft one you can use in your next refinement meeting.
