Why Estimates Disagree, and What the Gap Tells You

Two people estimate the same ticket. One says 3, the other says 13. It's tempting to read that as a failed estimate, something to smooth over by averaging the numbers or deferring to whoever sounds most sure.

It's the opposite. A wide gap is usually the most useful thing an estimation round produces. It means two people pictured different work, and one of them knows something the other doesn't. The number you settle on matters less than finding out which.

Disagreement is the point

Planning poker is a variation of Wideband Delphi^[1], an estimation method popularized by Barry Boehm in 1981. In Wideband Delphi, experts estimate anonymously, discuss the differences, and estimate again, round after round^[2]. The hidden first vote is deliberate. It stops the first number said aloud from becoming everyone's number.

That pull has a name: anchoring. In Tversky and Kahneman's classic experiments, people's numeric estimates drifted toward an arbitrary number they had just been shown, even when they knew it was arbitrary^[3]. Ask "this is about a 5, right?" in a planning meeting and you've anchored the room.

So the method is built to produce disagreement and bring it into the open. If every round agrees instantly, either your tickets are very well understood or people are copying each other.

Five reasons estimates disagree

1. They pictured different scope

The ticket says "Add CSV export to invoices." One person pictures a button and a query. The other pictures paging through ten years of invoices for a large customer, background jobs and an email when the file is ready. Both estimates are reasonable; they're just estimating different tickets.

What it tells you: the ticket is ambiguous. Fix the ticket, not the number.

2. Someone knows something

The low voter knows there's an export helper from last quarter that does most of the work. Or the high voter knows the invoices table has no index on the date column and the query will time out. One person holds information the rest of the team doesn't.

What it tells you: there's a hidden shortcut or a hidden risk. Hear the outlier first.

3. They disagree about what "done" means

One estimate includes tests, a migration, a feature flag and documentation. The other is just the code change. This is especially common when QA estimates alongside developers. A tester sees regression risk that a developer, thinking about the build, doesn't count.

What it tells you: the team's definition of done isn't shared, or isn't written down.

4. They know the area differently

Someone who has worked in this part of the codebase for two years sees a 2. Someone new to it sees an 8. Story points are meant to measure the work, not the person, but familiarity still shapes how big the work looks.

What it tells you: a knowledge silo. The team's estimate should assume the work might not go to the expert, and the ticket might be a good one to pair on.

5. The ticket is too big to see clearly

Spread grows with size. Two people rarely disagree between a 1 and a 2, but 8 against 21 is common, because nobody can hold all of a large ticket in their head. The Fibonacci scale's widening gaps exist for this reason. See Story points and the Fibonacci scale.

What it tells you: split it before you try to agree on a number.

Reading the gap

Once you know the usual causes, the shape of the votes is a good first clue:

Mike Cohn's advice for planning poker is to start with the highest and lowest estimates, because the high estimate often reveals hidden work, risk or complexity^[4]. That works for the patterns above too: you rarely need everyone's reasoning, just the two ends.

Don't average the gap away

Averaging feels fair. Averaging 3 and 13 gives 8, a number nobody voted for, about work nobody pictured. It throws away exactly the information the round produced. If the 13 was right about the timeout risk, an 8 still under-plans the ticket, and nobody looks at the database query.

The same goes for "majority wins" and for letting the most senior person decide. All three settle the number without settling the question. The fix is almost always cheap: one or two sentences from each end of the range, then a re-vote.

When the team isn't in the same room

In a live session, the high and low voter just talk. When a team estimates asynchronously, across time zones, there's no room to talk in, so the reasoning has to be written down. That's less natural, but it has a side benefit: the explanation stays with the ticket for whoever picks it up.

A simple rule that works: when a ticket's estimates disagree, the highest and lowest voter each leave one line explaining their number. Not a paragraph, just "I assumed we reuse the export helper" or "the invoices query has no date index." Most of the time, those two lines are enough for everyone to re-vote.

This is how Async Pointing Poker handles it. Everyone votes privately, on their own time. When every role on a ticket agrees, the ticket is accepted automatically. When any role disagrees, or someone votes "?", the ticket goes to the Scrum Master's review list. Most tickets need no discussion, and the time goes to the ones that do. The asynchronous sprint planning guide walks through the whole workflow.

How much disagreement is healthy?

There's no target number, but the trend tells you something:

• Most tickets disagree, every sprint. Tickets are reaching estimation before they're ready. Look at refinement, not estimation.
• Almost nothing ever disagrees. Either the work is very routine, or votes aren't really independent. Check that nobody sees anyone else's number before voting.
• The same people are always the outliers. That's a knowledge gap or an unwritten assumption worth a conversation outside planning.

The short version

• A wide gap means people pictured different work. Find out why before picking a number.
• Start with the highest and lowest voter; you rarely need anyone else's reasoning.
• Adjacent values are noise. Don't discuss them.
• Two clusters or a very high spread mean the ticket needs rewriting or splitting.
• Never average the gap away. You'd keep the number and lose the information.

Sources

1. ↩Planning poker (Wikipedia) — a variation of Wideband Delphi; hidden votes avoid anchoring
2. ↩Wideband delphi (Wikipedia) — anonymous, repeated rounds; popularized by Barry Boehm (1981)
3. ↩Amos Tversky and Daniel Kahneman, “Judgment under Uncertainty: Heuristics and Biases,” Science (1974) — the anchoring experiments
4. ↩Mike Cohn, “Planning Poker” (Mountain Goat Software) — start the discussion with the high and low estimates