You reveal the cards. Someone says 2. Someone else says 13. The room goes quiet.
This is not a problem. This is planning poker working exactly as designed. Divergent estimates surface hidden assumptions, missing information, and different mental models of the work.
The trick isn't avoiding disagreement. It's knowing what to do when it happens.
Why It Happens
Different Understanding of Scope
One person thinks "add login" means a simple form. Another is thinking OAuth, password reset, session management, and error handling.
Different Technical Approaches
Senior dev knows a library that solves this. Junior dev plans to build from scratch.
Different Risk Tolerance
Some people estimate the happy path. Others include testing, edge cases, and what could go wrong.
Hidden Dependencies
One person knows this touches the legacy authentication system. Others don't.
Experience Gaps
Someone who's done this before estimates differently than someone doing it for the first time.
Unclear Acceptance Criteria
The story says "make it responsive" but doesn't specify mobile, tablet, or both.
Example Scenarios
Add forgot password feature
High SpreadUpdate button color
Low SpreadMigrate to new database
Very High SpreadAdd analytics tracking
Medium SpreadIs It a Problem?
β οΈYes, it's a problem if...
- The team can't explain why they picked different numbers
- Discussion reveals the story is actually 3 different features
- People are solving different problems entirely
- The Product Owner realizes the requirements are unclear
- Someone includes question marks or coffee cups (infinite)
βNot a problem if...
- Estimates are within 1-2 Fibonacci steps (3 vs 5 is fine)
- The outlier can explain their reasoning clearly
- Quick discussion brings everyone to consensus
- Difference is due to experience, not misunderstanding
- Team agrees after hearing all perspectives
The Discussion Process
Step 1: Reveal Cards Simultaneously
Don't let anyone change their estimate after seeing others. The spread is the insight.
Step 2: Identify Outliers
Note the highest and lowest estimates. These are your conversation starters.
Step 3: Highest Estimate Speaks First
"You said 13. What are you accounting for that others might have missed?"
Step 4: Lowest Estimate Responds
"You said 2. What makes you confident this is simpler than others think?"
Step 5: Open Discussion
Let the team debate assumptions, technical approaches, and hidden complexity.
Step 6: Re-estimate
Pick cards again. If estimates converge, you're done. If not, repeat or defer.
Resolution Strategies
Ask the Outliers First
Start with the highest and lowest estimates. They often have critical information others missed.
Every time there's a significant spread
"You said 13 while others said 3. What are you concerned about?"
Break Down the Story
Divide the work into smaller, more granular pieces that are easier to estimate consistently.
When the story is genuinely complex or has hidden scope
Split "Add user authentication" into: setup, UI, backend, testing
Clarify Acceptance Criteria
Different estimates often mean different assumptions about what "done" means.
When team members are solving different problems
Does "mobile responsive" include tablet optimization?
Time-Box the Discussion
Set a 5-minute limit. If no consensus, take the higher estimate or defer.
When debate becomes circular or unproductive
Use the pessimistic estimate and move on
Do a Spike
For truly unknown work, create a time-boxed research task first.
When estimates include question marks or coffee cups
Spend 4 hours investigating the database migration path
Warning Signals
Same Person Always High
Meaning: They know something others don't, or they're risk-averse
β Ask them to explain their concerns upfront
Same Person Always Low
Meaning: They're overconfident or missing scope
β Have them walk through their implementation plan
Split by Role
Meaning: Frontend vs backend, or senior vs junior
β Missing shared understanding of the work
Everyone Confused
Meaning: Story needs refinement before estimation
β Send it back to the backlog
When to Re-estimate
After discussion, ask everyone to pick new cards. Most of the time, estimates will converge. If they don't, you have three options:
Take the Higher Estimate
When in doubt, pessimism wins. Better to be pleasantly surprised.
Split the Story
If the spread reveals hidden complexity, break it into smaller pieces.
Defer & Clarify
If the team is genuinely confused, send it back for refinement.
The Bottom Line
Wildly different estimates are not a bug. They're a feature. The spread forces conversation, surfaces assumptions, and builds shared understanding.
Don't rush to consensus. Let the outliers speak. They often know something critical that the rest of the team is missing. The goal isn't identical estimatesβit's informed estimates.
See It in Action
Practice handling divergent estimates with your team. Create a planning poker room in seconds.
Create Free Room



