← Back to blog

How to handle difficult estimates in Planning Poker

planning-poker estimates agile

Not every estimate will be easy. Some tasks generate votes of 3 and 21 in the same round, and even after discussion, the team still can’t agree. Here’s how to handle these situations.

Signs of a difficult estimate

  • Persistent extreme divergence — votes like 3 vs 13 after 3 rounds
  • “It depends” as the answer — nobody can estimate because decisions are pending
  • Everyone votes ? — nobody feels confident to give a number
  • Circular discussions — the team goes in circles without progress

What might be wrong

Poorly defined scope

If the story doesn’t have clear acceptance criteria, each member imagines something different. Solution: go back to the Product Owner and ask for clarification.

Unknown technical complexity

The team doesn’t know the technology or architecture involved. Solution: create a spike (research task) with a 1-2 day timebox before estimating.

External dependency

The task depends on another team, third-party API, or approval. Solution: estimate what’s under the team’s control, mark the dependency as a risk factor.

Task too large

A story that should have been an epic was insufficiently broken down. Solution: decompose the task into smaller, more manageable parts.

Practical strategies

1. Rule of 3 rounds

Maximum 3 rounds of voting and discussion. If no consensus, the task leaves the session and returns after refinement.

2. Range estimate

Instead of forcing a number, accept “between 8 and 13 points.” This communicates uncertainty and helps with buffer planning.

3. Vote uncertainty

Use a second voting dimension: besides points, vote on confidence (high, medium, low). Low-confidence estimates deserve special attention.

4. Analogical reference

Find a similar already-estimated and delivered item. Use that as a starting point: “Task X was 5 points and this seems 20-30% more complex, so it’d be 8.”

5. Facilitator’s decision

As a last resort, the facilitator or most experienced member decides, but with a clear caveat: “We’ll assume 8 points, but if we discover it’s more when starting, we reprioritize.”

When to postpone the estimate

Don’t be afraid to not estimate an item. If the team lacks sufficient information, it’s better to be honest than create false confidence. Mark for:

  • Refinement with more PO details
  • Technical spike to investigate feasibility
  • Discussion with architects or specialists

Conclusion

Difficult estimates aren’t team failures — they’re signals that something needs clarification. Respecting uncertainty is more mature and productive than forcing a number everyone knows is wrong.