The estimate is a distribution

“Roughly how long for the checkout?”

Nine people in the room, one of them a client, and everyone has stopped talking and is looking at me. And what I know, genuinely and precisely, is something like this: if the payment provider’s sandbox behaves the way it did on the last two projects, about five days. If their documentation is still describing the previous version of the API, more like nine. If there’s a 3-D Secure requirement nobody has mentioned yet, which there might be, two weeks and a bad two weeks.

What I said was “about a week.”

By Thursday “about a week” was a bar on a Gantt chart, with a start date and an end date, and the words “about” and “roughly” had evaporated somewhere between my mouth and the document, as they always do.

What I actually believe is a shape

The thing I’ve slowly become convinced of is that the mistake isn’t in the number. The number was a reasonable summary of what I thought. The mistake is in the format of the question, and I keep answering in the format I’m asked in.

An honest estimate isn’t a value, it’s a probability distribution. There’s a range of outcomes and they have different likelihoods, and my expertise, such as it is, lives in the shape rather than in the peak. Knowing that the payment provider is the risky part is the estimate. Saying “a week” throws that away and keeps the least useful summary of it.

My expertise lives in the shape of the curve, not the peak of it. Saying "about a week" throws away everything I actually know and keeps the one number I'm least sure of.

The tail only goes one way

Here’s the bit that took me longest to see and that explains a lot of my career.

The distribution isn’t symmetric, and it can’t be. It’s bounded on the left by zero and unbounded on the right. The absolute best case is that everything goes perfectly and it takes three days. The worst case has no ceiling at all: I’ve had a two-day job take five weeks because a hosting provider’s SSL setup turned out to be non-standard in a way nobody could explain.

So the curve leans hard to the left with a long tail dragging off to the right, and the consequence of that shape is the thing that gets everyone. The most likely outcome, the peak, is lower than the average outcome, because the average is pulled right by the tail.

Which means if I estimate honestly by naming the most likely case, and I do that 40 times a year, I will be late more often than I’m early even though every single estimate was given in good faith. Not because I’m bad at this. Because “most likely” and “on average” are different numbers, and the plan is built out of the first one and the year is made of the second.

I found that consoling when it landed, having spent about four years assuming I was simply worse at estimating than other people. Everyone is worse at estimating than other people.

You estimate the job you can imagine

The second structural thing, which compounds the first.

When I estimate, I’m simulating the work in my head, and I can only simulate the parts I can picture. I picture writing the form, wiring the API, handling the error states. Five days, and it’s a good five days.

What I can’t picture is the specific unknown thing, because if I could picture it, it’d be in the estimate. I can’t picture that the client’s merchant account is in a different legal entity’s name and the provider will take nine working days to verify it. Nobody could picture that. It happened in March.

But here’s the move: while I can’t predict the specific surprise, I have excellent data on the base rate. Something like that happens on most projects. I know that from ten years of it happening. So the estimate has to include a term for “the thing I can’t see,” and the size of that term comes from history rather than from imagination.

Which is why comparing against past work beats decomposing the task. Every time I’ve broken a job into 14 items and added them up, I’ve got a number lower than what the last three similar jobs actually took. Every single time. The last three jobs include all the surprises. The decomposition includes none of them, because you can’t itemize a surprise.

Say a range, and why

Not a number. A range, plus the reason for the width, plus what I’d do about it.

Roughly: “Three to twelve days. The three assumes the payment sandbox works the way their docs say, and the twelve is if it’s like the last two projects. If you give me half a day to build a throwaway test against their sandbox, I can probably tell you by Wednesday which end we’re at.”

That does three things. It’s honest, so I’m not carrying a private worry I’ll resent later. It moves the conversation to the actual risk, which is where all the money is, rather than to a number nobody can interrogate. And it offers a way to buy the uncertainty down, which clients say yes to far more often than I expected, because half a day to remove a nine-day tail is obviously a good trade when you put it like that.

The buffer, and why I’ve stopped

The traditional approach is to work out an honest number and then double it, which is a real thing that real professionals do and which I did for years.

It doesn’t work, for two reasons. It’s a lie, so it gets treated like one: the client knows there’s padding, so they negotiate against the padding, and now you’re haggling over a fiction. And it hides the information. A doubled number is a confident number with the reasoning removed, so nobody can act on the risk, because nobody knows what the risk was.

A range with a reason attached can’t be negotiated in the same way, because there’s nothing to haggle with. You can’t argue the payment provider into being more predictable.

The question underneath

The last thing, and it’s saved me more grief than any of the above.

“How long will it take” is usually not the question. The real question is nearly always a decision: can we launch before the trade show, will this fit in this quarter’s budget, do we need to tell the client’s board something in January.

If I answer the decision instead of the estimate, most of the difficulty evaporates. “It won’t be ready for the trade show if the payments work is in scope, and it comfortably will be if we launch with an inquiry form and add checkout in February” is an answer somebody can actually use. It also happens to be a much easier thing for me to be confident about than a number of days.

Say the shape

I went looking for other people writing about this before I started and found almost nothing, which surprised me, given that every developer alive does it every week and is bad at it. There’s a huge literature on agile process and points and velocity, and almost nothing on the plain human problem of being asked a question whose honest answer is a shape.

So: it’s a shape. Say the shape. Say what makes it wide, and offer to make it narrower.

And don’t say a number in a meeting. That one’s free 🥲