Planning poker is simple in theory. In practice, teams find creative ways to break it. Some mistakes are obvious (averaging Fibonacci numbers). Others are subtle (skipping discussion on unanimous votes). All of them make your estimates worse.
Here are the 10 most common mistakes, the warning signs you're making them, and practical fixes you can implement immediately. No theory—just what actually goes wrong and how to stop it.
Letting the Product Owner Vote
⚠️ Warning Signs
- •PO picks a card "just to participate"
- •Team looks to PO for guidance on estimates
- •Discussion focuses on what PO wants instead of technical reality
Why It Hurts
The PO isn't implementing the work. Their vote either reflects wishful thinking (lower estimates to fit more in the sprint) or fear (higher estimates for buffer). Both corrupt the process.
✓ The Fix
Only implementers vote. PO clarifies requirements but stays silent during estimation. If they have complexity insights, they share them before voting starts.
How to Enforce
Facilitator explicitly says: "PO, your job is to answer questions, not estimate. Put your cards away."
Sequential Card Reveals
⚠️ Warning Signs
- •Going around the table one by one
- •Senior developer always "goes first"
- •Estimates cluster around the first number mentioned
Why It Hurts
This destroys the entire psychological foundation of planning poker. Anchoring bias means the first estimate disproportionately influences everyone else. You've just reinvented inefficient group averaging.
✓ The Fix
Everyone holds their card face-down, then reveals simultaneously on a countdown. Use a digital tool that enforces this if remote.
How to Enforce
Physical cards: "3, 2, 1, flip." Digital tools: built-in simultaneous reveal. No exceptions.
Averaging the Numbers
⚠️ Warning Signs
- •Calculator comes out after voting
- •Estimates like "6" appear (not in Fibonacci sequence)
- •Someone says "let's just split the difference"
Why It Hurts
Fibonacci is non-linear for a reason. Averaging 3 and 8 to get 5.5 (rounded to 5) erases valuable information about uncertainty. The wide variance was telling you something important.
✓ The Fix
If votes are 3, 5, 8: discuss why they differ, then re-vote. If consensus is 5 and 8, pick 8 for safety or break down the story.
How to Enforce
Ban calculators from estimation sessions. Only Fibonacci values are allowed as final estimates.
Estimating in Hours Instead of Points
⚠️ Warning Signs
- •Debates about whether someone works faster than others
- •Estimates account for meetings and interruptions
- •Micromanagement about who's assigned which tasks
Why It Hurts
Time estimates encourage comparison of individual productivity, create pressure to work faster, and ignore the reality that estimation accuracy decreases for longer work.
✓ The Fix
Estimate relative complexity using story points. Track team velocity over sprints. Use historical data to predict timelines, not upfront hour estimates.
How to Enforce
Remove all time references from estimation. Calibrate team on a reference story (e.g., "This login form we built last month was a 5").
Skipping Discussion on Close Estimates
⚠️ Warning Signs
- •When everyone votes 5, facilitator immediately moves on
- •No one asks "Why 5 instead of 3?"
- •Fast consensus feels efficient and productive
Why It Hurts
Unanimous agreement can mean shared understanding—or shared ignorance. If everyone quickly agrees, you might all be missing the same complexity.
✓ The Fix
Even with unanimous votes, ask: "Anyone see risks or gotchas?" Give 30 seconds of silence for second thoughts. Occasionally that surfaces hidden complexity.
How to Enforce
Mandatory "last call for concerns" even on unanimous votes. Silence is fine; rushing isn't.
Forcing Estimates on Vague Stories
⚠️ Warning Signs
- •Team asks clarifying questions but PO can't answer
- •Multiple people play the ? card
- •Final estimate has huge variance or reluctant consensus
Why It Hurts
Garbage in, garbage out. Estimating unclear work leads to wildly inaccurate sprint planning. You commit to work you don't understand.
✓ The Fix
If more than 30% of team plays ?, the story goes back to refinement. Don't force numbers on ambiguity.
How to Enforce
Set a rule: "3+ question marks = story not ready." PO refines it offline and brings it back next session.
Ignoring Outlier Explanations
⚠️ Warning Signs
- •Highest estimator explains concerns, team dismisses them
- •Someone votes 13 while others vote 3, but no discussion happens
- •Assumption that the outlier "just doesn't get it"
Why It Hurts
Outliers often spot risks the majority missed. The junior dev who votes 8 when seniors vote 3 might know about a bug in the codebase others forgot.
✓ The Fix
Outliers speak first. Team listens without interrupting. Then re-vote. If the outlier was wrong, estimates will converge. If they were right, estimates will adjust.
How to Enforce
Facilitator explicitly asks: "Highest and lowest, what did you see that led to your estimate?" Make it a ritual.
Using Planning Poker for Everything
⚠️ Warning Signs
- •Estimating 1-point stories that take 10 minutes to implement
- •Debating whether a typo fix is 0 or 1 points
- •Estimation sessions take longer than doing the work
Why It Hurts
Overhead isn't justified for tiny tasks. You waste team time on precision that doesn't matter.
✓ The Fix
Batch trivial tasks into a single "minor fixes" story or just do them without estimation. Reserve planning poker for work that actually benefits from discussion.
How to Enforce
Set a threshold: "Sub-30-minute tasks don't need estimation. Batch them or just do them."
Changing Estimates Mid-Sprint
⚠️ Warning Signs
- •Developer realizes story is bigger than estimated, so they update the estimate
- •Velocity calculations change during the sprint
- •Team treats estimates as living documents
Why It Hurts
Estimates are snapshots of knowledge at planning time. Changing them mid-sprint corrupts velocity tracking and prevents learning from estimation errors.
✓ The Fix
Estimates are locked once sprint starts. If work expands, note it for retro but don't change the original estimate. Track actual vs. estimated for learning.
How to Enforce
Make estimates read-only after sprint planning. If story explodes, create new stories for additional work.
Optimizing for Speed Over Understanding
⚠️ Warning Signs
- •Estimation sessions are timed and rushed
- •Facilitator pushes team to "just pick a number"
- •Pride in finishing estimation in record time
Why It Hurts
The value isn't the number—it's the shared understanding from discussion. Rushing eliminates the learning and alignment that make planning poker useful.
✓ The Fix
Slow down. Let discussions breathe. If a story takes 10 minutes to estimate because it sparked valuable technical conversation, that was time well spent.
How to Enforce
Measure success by sprint delivery accuracy, not estimation speed. A slow, thoughtful estimate beats a fast, wrong one.
Quick Reference: Red Flags
Print this checklist and review it after each estimation session. If you see 3+ red flags, your process needs fixing.
The Bottom Line
Most planning poker failures aren't because the technique is flawed—they're because teams skip the parts that feel slow or awkward. The simultaneous reveal feels ceremonious. Discussing outliers takes time. Sending vague stories back to refinement delays sprint planning.
But those "inefficiencies" are the entire point. They force conversation, surface hidden complexity, and create shared understanding. Skip them to save 5 minutes, lose hours to miscommunication later. The choice is yours.
Fix Your Estimation Process
Run a clean planning poker session. Simultaneous reveal. Outlier discussion. No shortcuts.
Create Free Room