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 Spread
2
3
5
13

Update button color

Low Spread
1
1
2
1

Migrate to new database

Very High Spread
8
13
21
?

Add analytics tracking

Medium Spread
3
5
5
5
πŸ€”

Is 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

5 sec

Step 1: Reveal Cards Simultaneously

Don't let anyone change their estimate after seeing others. The spread is the insight.

10 sec

Step 2: Identify Outliers

Note the highest and lowest estimates. These are your conversation starters.

1-2 min

Step 3: Highest Estimate Speaks First

"You said 13. What are you accounting for that others might have missed?"

1-2 min

Step 4: Lowest Estimate Responds

"You said 2. What makes you confident this is simpler than others think?"

2-3 min

Step 5: Open Discussion

Let the team debate assumptions, technical approaches, and hidden complexity.

5 sec

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.

When to Use

Every time there's a significant spread

Example

"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 to Use

When the story is genuinely complex or has hidden scope

Example

Split "Add user authentication" into: setup, UI, backend, testing

Clarify Acceptance Criteria

Different estimates often mean different assumptions about what "done" means.

When to Use

When team members are solving different problems

Example

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 to Use

When debate becomes circular or unproductive

Example

Use the pessimistic estimate and move on

Do a Spike

For truly unknown work, create a time-boxed research task first.

When to Use

When estimates include question marks or coffee cups

Example

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