Disagreement is the point
The goal of planning poker was never a fast, unanimous number. If everyone always agreed, you could skip the cards and let one person estimate. The value is in the moments the cards don't match: the outliers have seen something the rest of the team hasn't, or they're missing context everyone else has. Either way you'd rather find out now, in a refinement meeting, than mid-sprint. Treat a wide spread as a discovery, not a delay.
Start with the outliers
After a reveal with a wide spread, ask the highest and lowest voters to explain first — not to defend their number, but to describe what they were picturing. The high voter usually knows about a dependency, a gnarly edge case, or past pain with similar work. The low voter often has a simpler implementation in mind, or knows a shortcut. Ordering it this way surfaces the two extremes of understanding immediately and keeps the middle from just averaging.
Expose the hidden assumptions
Most estimate gaps trace back to an unstated assumption: "I assumed we reuse the existing component," "I assumed this needs a migration," "I assumed the API already returns that field." The facilitator's job is to make each assumption explicit and check it against reality. Half the time, one sentence resolves the gap — everyone was estimating a slightly different story. The rest of the time you've found a genuine unknown, which is itself the answer.
Use confidence and rationale, not just the number
A number alone hides how sure the voter is. Pairing each card with a confidence signal and a one-line rationale changes the conversation: a confident 8 and an unsure 8 mean different things, and a tight spread where everyone is low confidence deserves more scrutiny than a wide spread where the extremes are both certain. This is the same rationale/confidence data that makes async planning poker work — it lets you spend discussion time where the actual uncertainty is.
After a reveal, Pokor can summarize where the team diverged and why — turning a wall of cards and comments into a short list of the assumptions worth discussing. One credit, only when you ask for it.
Timebox the debate
A single contested story can eat an entire refinement session if you let it. Cap the discussion — three to five minutes is plenty for most gaps. The point of the timebox isn't to rush; it's to force a decision. If the assumptions are surfaced and the team converges, great. If five minutes pass and the gap holds, that's not a failure — it's the story telling you it isn't ready, and the timebox is what makes you act on that instead of grinding.
Re-vote once
After the outliers explain and the assumptions are on the table, re-vote — once. Usually the spread collapses because everyone is now estimating the same story. If it collapses, record the estimate and move on. Resist the urge to re-vote three or four times chasing unanimity; the second vote captures the value of the discussion, and further rounds just pressure people to conform.
When it still won't converge: split, spike, or park
If one re-vote doesn't close the gap, the disagreement is real and structural. You have three honest moves:
- Split — the story is bundling separable work with different risk profiles. Break it apart and estimate the pieces; see how to split user stories.
- Spike — the gap is a genuine unknown. Timebox a small investigation to learn what you need, then re-estimate with real information.
- Park — the story isn't ready and isn't blocking the sprint. Move it back to the backlog and refine it before it comes up again.
What you should not do is average the votes and move on. An averaged estimate papers over the exact uncertainty the ceremony just uncovered. The PMI's overview of agile estimation techniques makes the same point: the conversation, not the consensus number, is what makes the estimate trustworthy. A team that treats disagreement as signal estimates better every sprint — see story point estimation for how that calibration compounds over time.