Estimation is a conversation, not a number

I don't ask teams for estimates, and I do ask them to have the conversation that estimation was supposed to provoke.

Those two fit together once you notice what the exercise actually produces.

Five engineers privately think a task is a day, a day, a day, a week, and "we can't do that until we know how the permissions model works."

The useful output is not the average. It's the fifth person.

The number was never the point, and averaging it away destroys the only information the meeting generated.

What a wide spread means

A big disagreement about size is almost never a disagreement about speed.

It's a signal that people are estimating different pieces of work, because they're holding different pictures of the problem.

That happens for a small number of reasons and it's worth naming which one is in play.

Somebody knows something the others don't.

The person saying a week has remembered this touches the legacy sync. They're right, and the meeting just paid for itself.

The requirement is ambiguous. Two people are estimating two different features, both plausible readings of the same ticket. Better to find that now than in review.

Or the work is genuinely unknown, and nobody can size it until somebody spends a day finding out.

That's a real answer. The correct move is a timeboxed investigation, not a number produced to satisfy a process.

So if you keep any part of estimation, keep this.

Whenever the spread is wide, stop and talk about why, and don't move on until the reason is one of those three.

Then throw the numbers away. They've done their job.

The unit doesn't matter

Points, t-shirts, days, animals. It genuinely doesn't matter, and every long argument about which unit to use is a proxy for a different problem.

What matters is whether the unit gets converted into a commitment somewhere upstream.

Points become velocity. Velocity becomes a forecast. The forecast becomes a promise made to a customer, and now a number invented to help a team discuss complexity is a contractual obligation.

The team learns this inside a quarter and the numbers inflate accordingly, at which point they measure nothing at all.

The tell is simple: if anyone outside the team can tell you what the team's velocity is, estimation has stopped being a conversation and become a reporting system.

Forecast from throughput instead

Here's the part most people don't know.

You can forecast delivery perfectly well without estimating anything, and the forecast is usually better.

Count how many work items your team finished in each of the last ten weeks.

That's throughput. A real measurement rather than a prediction, and it already includes everything estimates systematically omit: interruptions, holidays, the incident, the two days lost to a flaky test, the thing that turned out to be harder than it looked.

To forecast twenty items: divide by weekly throughput for a rough middle, then look at your worst weeks for the pessimistic case.

Team finishes between four and nine items a week? Twenty items is somewhere between two and five weeks. And you can say that with a straight face, because it's arithmetic on observed history rather than a hope.

If you want the more precise version, run a Monte Carlo simulation over your historical weekly counts. It takes about twenty lines of code or a spreadsheet, samples from your actual past, and gives you an honest distribution: an 85% chance of finishing by a given date, say. Free forecasting tools do it, and most teams that try it never go back.

Two things this requires.

Items roughly similar in size, which mostly happens on its own if you're breaking work down to ship in a few days. And ten weeks of history, so a brand-new team estimates for a while, or borrows a similar team's numbers. That's fine.

What throughput can't do is tell you about work unlike anything you've done.

First integration with a new payment provider. A migration nobody has attempted. There, forecast nothing and timebox an investigation instead.

The steel-manned case for estimating anyway

I don't want to pretend this is settled, because the pro-estimate argument has a real core.

Somebody outside engineering often has a decision that depends on rough size.

Is this a two-week thing or a six-month thing, because if it's six months we should sell something else this quarter.

Legitimate question. It needs an answer before the work starts, and throughput can't give it for work that hasn't been broken down yet.

The answer is that this question deserves a proper conversation and about an hour of senior engineering time, not a sprint ritual. Sit with the person, understand the decision they're making, and give a range: weeks not months, months not weeks, or we don't know and here's the cheapest way to find out.

The second real argument: estimating forces decomposition.

And decomposition is genuinely valuable, because splitting a big thing into pieces is how you find out what's actually in it.

That's true, and it's an argument for decomposition, not for numbers. Break work down until each piece can ship on its own within about a week. You get the same discovery benefit, and you get small batches as a side effect.

Making the switch without a fight

Don't announce that estimation is abolished.

That's a philosophical position, and it invites a philosophical argument you'll have every quarter with a new stakeholder.

Do it by substitution.

Produce a throughput-based forecast alongside whatever the current process produces. Six weeks. Show both.

The throughput one will be more accurate, and somebody other than you will notice.

Then propose dropping the estimation step on the grounds that it's producing a worse forecast for more effort. That's an efficiency argument, made with evidence, and it lands very differently from a manifesto.

What you must keep, visibly, is the answer the estimates were serving.

When will this be done, and how confident are you.

Remove the ritual without replacing the answer and you'll get the ritual back inside two quarters. Next time it arrives with a tool attached.