How I estimate software: ranges, not dates

Early in my career, a manager asked how long a feature would take, and I said "Tuesday." I don't know why I said Tuesday. I wanted to sound like someone who had it handled. It was not done Tuesday. It wasn't done the Tuesday after that either.

I've given a lot of estimates since then, and the biggest thing that changed isn't that I got better at predicting the future. I didn't. What changed is that I stopped pretending a single date was an honest answer.

Now I estimate in ranges. Here's why, and how.

A date is a lie with a due time on it

When you give one date, you're making a promise about a version of reality where nothing surprises you. Where the third-party API you've never touched behaves exactly like its docs. Where the requirement doesn't quietly change the moment someone sees the first screen. Where you don't get pulled onto an incident for two days.

None of those are edge cases. They're Tuesday. A single date pretends the unknowns don't exist, and then reality bills you for the difference, usually in front of the whole team.

What a range actually says

"Three to five days, and I'll know which end by tomorrow" is not hedging. It carries more information than a date, not less:

• the lower bound is what happens if the work is as simple as it looks
• the upper bound is what happens if the parts I haven't seen yet fight back
• "I'll know by tomorrow" tells you exactly when the range will narrow

That last part matters most. A good estimate isn't a fixed number, it's a number that gets sharper as the unknowns close. The job of the first day is to kill the biggest uncertainty, so the range collapses toward one end.

Where the range comes from

I break the work into pieces small enough that I've done something like each one before. The pieces I recognize, I can estimate tightly. The pieces I don't, the new API, the legacy module nobody understands, the "it should just be a config change" that never is, those are where the range lives. The width of my estimate is basically a measure of how much I haven't seen yet.

If a task has no wide parts, I give a tight range. If it's mostly unknowns, the honest answer is a wide one, and the honest next step is to spend an hour shrinking it before I commit to anything.

Handling the pushback

Someone will ask for "the real number." I get it, a range can feel like dodging. So I don't just hand over two numbers, I hand over the reason: "Five days if the payment provider's sandbox works like the docs say. Eight if it doesn't, and I've been burned by that sandbox before." Now the range isn't me being vague. It's me being specific about the exact thing that will decide it.

Stakeholders don't actually want false confidence. They want to plan. A range they can trust is worth more to them than a date they'll have to renegotiate.

The real point

Estimation isn't fortune-telling, and pretending it is has a cost: it trains everyone to expect certainty you can't deliver, and then to treat every honest "it depends" as a failure.

A range says the true thing out loud. Here's what I know. Here's what I don't yet. Here's when I'll know more. That's not a weaker answer than a date. It's the only kind of answer that survives contact with a real project.