What to Do When Your Team Can't Agree on an Estimate

One round of disagreement is normal. Two rounds often resolve it. When the team is still split after three rounds, you're not dealing with an estimation problem: you're dealing with a knowledge or scope problem.

Diagnosis: what kind of disagreement is this?

Type 1: Different assumptions about scope One developer is thinking about a full implementation including error handling, logging, and tests. Another is estimating just the happy path. The disagreement is about what "done" means.

Fix: Re-read the acceptance criteria aloud. If they don't resolve the ambiguity, the story needs more definition before it can be estimated.

Type 2: Different knowledge of the codebase One developer knows a particular module is a mess and expects hidden complexity. Another hasn't worked in that area and is estimating based on surface-level reading.

Fix: Ask the high-estimator to share what they know. If the knowledge is specific enough to affect the estimate, it should affect everyone's estimate. Document it in the story.

Type 3: Different risk tolerance Some developers habitually add buffer; others estimate optimistically. Neither is wrong, but they'll never converge if the underlying philosophy differs.

Fix: Agree on a team norm: are you estimating the expected case or the protected case? Once that's explicit, it becomes easier to calibrate.

When to stop and park the story

If you've had three rounds of voting and the spread is still wide, the story isn't ready. Park it with a note about what's blocking consensus, and add a task to resolve it before the next planning session, often that task is splitting the story.

A story that can't be estimated usually can't be delivered predictably either.

Persistent disagreement is useful information. Don't average your way past it: use it to figure out what you don't yet know.