Common planning poker mistakes and how to fix them
Planning poker is simple in principle but easy to get wrong in practice. The most damaging mistakes undermine the statistical validity of the estimates themselves. This guide covers the most common errors — from anchoring to scale drift — with actionable fixes.
Mistake 1: Discussing complexity before voting
The most fundamental mistake in planning poker is allowing discussion before the votes are cast. When one team member says "this feels like a 5" before voting, they anchor every subsequent estimate. Other team members adjust toward the stated value rather than forming independent estimates.
This defeats the entire statistical purpose of simultaneous reveal. Planning poker's accuracy relies on the wisdom of crowds — independent estimates that are then aggregated through discussion. Pre-reveal discussion removes the "independent" part.
Fix: enforce a strict rule: no complexity discussion before the reveal. Factual clarifying questions ("Is this story including the mobile view or desktop only?") are acceptable; opinion statements ("I think this is straightforward") are not. The facilitator should politely interrupt and redirect any pre-reveal complexity comments.
Mistake 2: Skipping the reveal discussion
The opposite mistake: voting, revealing, and accepting the average without any discussion. Teams that do this get numbers but miss the value. Planning poker discussions surface hidden assumptions, architectural risks, and scope ambiguities that the estimates alone cannot reveal.
When all votes are the same, a brief discussion is still worth 30 seconds to confirm everyone is thinking about the same thing. When votes diverge, the discussion is mandatory — it is the primary deliverable of the session.
Fix: make discussion a non-negotiable part of every reveal. For unanimous votes, ask: "Does everyone agree on why this is a 3? Any hidden assumptions?" For diverging votes, always ask the highest voter first.
Mistake 3: Team members not voting
It is common for some team members — particularly junior developers or new team members — to skip voting or simply wait to see what others select before committing. This reduces the sample size and reintroduces the anchoring problem.
Every team member who will work on the stories should vote. New team members' votes are especially valuable because they often see complexity that experienced members have normalised into invisibility.
Fix: use a tool that requires all participants to vote before the reveal is possible. Set the expectation during onboarding that voting is required. When a new team member abstains, ask them directly: "What would you guess, even if you're uncertain?" Make uncertainty a valid vote (most tools have a question mark card) rather than a reason to abstain.
Mistake 4: Estimating stories that are too large
Trying to estimate a story that should be an epic is a common time sink. The team cannot converge because the story is so large and ambiguous that individual mental models differ too dramatically. Multiple rounds of voting produce nothing useful.
The high variance is not an estimation failure — it is useful information. The team cannot agree because there genuinely isn't enough clarity to estimate.
Fix: establish a maximum estimate threshold (many teams use 8 or 13). If a story consistently receives votes above this threshold, it is a split trigger — stop estimation and split the story into smaller items before the next session.
Mistake 5: Letting the scale drift over time
Scale drift happens when the team's definition of "a 5" gradually changes over time without anyone noticing. A new team member joins and their mental model of a 5 is different; an experienced developer leaves and takes their calibration anchor with them; the team completes a particularly hard project and recalibrates informally.
Scale drift makes velocity data incomparable across time. A team that completed 40 points per sprint last quarter and 50 points per sprint this quarter may not be moving faster — they may simply be calling the same stories bigger numbers.
Fix: maintain 2–3 reference stories as permanent scale anchors. Revisit them at least once per quarter. If the team's intuition about a reference story's size has changed, run an explicit recalibration session.
Mistake 6: Running planning poker without story context
Estimating a story without reading the acceptance criteria, reviewing the design mock-ups, or understanding the technical constraints produces estimates that don't reflect the actual work. The team is voting on their imagination of the story, not on the story itself.
This is particularly common in remote sessions where stories are added to the tool list but relevant context (Jira ticket, Confluence spec, wireframe) is not shared before voting.
Fix: require that every story is read aloud and all relevant context links are shared before voting begins. If context is missing, defer the story for refinement rather than estimating without it.
Planning poker mistakes FAQ
How do we handle a team member who consistently anchors others?
Address it in a retrospective as a process improvement, not a personal criticism. Frame it as: "Our planning poker results would be more accurate if everyone voted simultaneously without sharing initial reactions." Make the rule explicit and apply it consistently.
What if the team disagrees after three rounds of voting?
After three rounds without convergence, the story is not estimable with current information. Record it as unestimated, add clarification tasks to the backlog, and move on. Do not force consensus through attrition.
Is it a mistake to use planning poker for every story?
For very small stories (0.5 or 1 point) that are trivially clear, estimation overhead may exceed the value. Many teams batch-vote on groups of trivially similar micro-tasks. The key is that the decision to skip estimation is deliberate, not lazy.
Run a better planning poker session — start free with ScrumVote