How much discussion time is too much in planning poker?

Amy Chen
Amy Chen · Nov 20, 2025 at 1:00 PM

Our planning poker sessions are dragging on forever. Yesterday we spent 15 minutes debating a single story about adding a filter to a report page.

How long should discussions last before we just pick an estimate and move on? What's the right balance between thorough analysis and efficiency?

Efficiency Expert
Efficiency Expert Best Answer · Nov 20, 2025 at 2:15 PM

Rule of Thumb: 5 Minutes Max Per Story

Here's the protocol that works for most teams:

  1. Read story + clarifying questions: 2 minutes
  2. First vote + reveal: 30 seconds
  3. Discussion (if votes differ): 2-3 minutes
  4. Second vote: 30 seconds
  5. Decision: immediate

Total: ~5 minutes per story

When to Cut Discussion Short:

  • Team is debating implementation details (not estimation)
  • Same two people keep arguing back and forth
  • Discussion reveals missing requirements (defer story, get PO clarification)

The 2-Vote Rule:

If votes don't converge after 2 rounds, take the higher estimate and move on. You're spending more time estimating than it would take to just build the thing.

Signs You Need to Stop:

  • "We've been discussing this for 10 minutes"
  • "We're designing the solution instead of estimating complexity"
  • "Nobody has new information to add"

Remember: Planning poker is about quick, good-enough estimates, not perfect ones. The goal is predictability, not precision.

Scrum Guide
Scrum Guide · Nov 20, 2025 at 3:00 PM

I use a timer. Literally set a 5-minute timer on my phone for each story. When it beeps, we vote one last time and move on. Teams adapt quickly when they know time is limited.

Amy Chen
Amy Chen OP · Nov 20, 2025 at 4:00 PM

The 5-minute timer idea is great! I'll propose this to the team. We definitely fall into the trap of designing solutions instead of just estimating complexity.

Team Facilitator
Team Facilitator · Nov 20, 2025 at 5:00 PM

Also: if a story consistently generates long debates, it's probably too big or too vague. Either split it into smaller stories or send it back to the product owner for more detail.

Related Discussions