Estimates as ranges

Point estimates age badly.

They turn uncertainty into a promise, and then everyone has to pretend the promise was reasonable.

A range isn’t a way to dodge responsibility. It’s a way to keep responsibility attached to reality.

A good range is:

• bounded (it doesn’t span seasons)
• controlled by an assumption (one thing you’re trying to prove)
• paired with a checkpoint (when the range will move)

A bad range is “two weeks to two months.” That’s not a plan; that’s a shrug.

Be explicit about what the range covers:

• calendar time, not “engineering days”
• whether approvals, vendor response, or data cleanup are inside the range or outside it
• whether the work is blocked on someone else (and by whom)

Ranges are also a forcing function for scope. If you can’t make the range smaller, the answer might not be “estimate harder.” The answer might be “ship less.”

One practical trick: write the optimistic case and the pessimistic case as two sentences. If you can’t name what makes the pessimistic case slower, you’re not estimating—you’re negotiating.

If your range never changes, you’re not learning. You’re just repeating a number.

Takeaways

• Give a range, not a point.
• State the assumption that controls the range (integration works as expected, data is clean, etc.).
• Name the next decision point (“after discovery”, “after the first integration test”).
• Update the range at that checkpoint. Don’t defend the old number.

A copy/paste pattern we use:

• Range: …
• Assumptions: …
• Biggest unknown: …
• Next checkpoint: …

Example (early in a project):

• Range: 2–4 weeks after discovery
• Assumptions: vendor API supports bulk export; data maps without manual cleanup
• Biggest unknown: rate limits + pagination edge cases
• Next checkpoint: first end-to-end export run (Tuesday)

Further reading

• We do not lie to make work feel safer
• Status updates that don’t lie