“Two weeks” is a lie the moment you say it as a single number. Not because you’re bad at estimating, but because a point estimate throws away the only useful information you have: how sure you are.

Why single numbers fail

When you say “two weeks,” the person hearing it stores it as a commitment, not a guess. Then when it takes three, it reads as a miss, even though a competent estimator knew from the start that “two weeks” meant “somewhere between one and five, probably around two.” The number was honest. The way it got communicated wasn’t.

Estimate in ranges, always

Low:      3 days  (if the API behaves like the docs say)
Likely:   6 days
High:     12 days (if we need to build our own webhook retry logic)

The gap between low and high is itself information — it tells the listener how much is still unknown, not just how long the task is. A tight range means you understand the problem. A wide range means there’s real uncertainty, and that’s worth saying out loud instead of hiding inside a fake-precise single number.

Where the uncertainty actually comes from

Almost never from typing speed. It comes from:

• Integration points you don’t control — a third-party API, another team’s service, a legacy system with no docs.
• Requirements that aren’t actually settled, even if everyone in the room thinks they are.
• Work that’s “the same as last time” but isn’t — the previous instance had different data, different scale, different edge cases.

Name the specific uncertainty instead of padding the number to compensate for it:

Estimate is 4-8 days. The swing depends on whether the legacy export format is consistent across all customer accounts — we’ve only verified three.

That sentence does more for the listener than any number could, because it tells them exactly what would need to be true for the low end to happen.

Break it down until the pieces are boring

A two-week estimate for “add SSO” is a guess. A breakdown into “wire up the OIDC library” (1 day), “map claims to our user model” (1 day), “handle the account-linking edge case for existing email/password users” (3-5 days, uncertain), “add the enterprise admin config UI” (2 days) is a set of smaller guesses that are individually much easier to be right about, and the sum is more honest than the single number ever was.

The account-linking line is also where the real risk lives, and breaking it out means that’s visible to everyone, not buried inside an aggregate that looks fine on the surface.

Communicating uncertainty to non-engineers

Don’t say “it depends” without following it with what it depends on. “It depends” sounds evasive to someone who needs to plan a launch date. “It’s 4-8 days depending on whether the legacy data is clean, and we’ll know by Wednesday” is the same uncertainty, stated as a plan instead of a shrug.

Give a date to reduce the uncertainty, not just the range itself:

We’ll know by Wednesday whether it’s the 4-day path or the 8-day path.

That single sentence turns an anxious stakeholder into someone who has something concrete to wait for.

What to never do

Never let padding be the only response to uncertainty. Doubling every estimate “to be safe” just trains everyone to mentally halve whatever number you give them, which puts you back to square one with extra steps. State the actual range and the actual reason for it — that’s the only version of the estimate anyone can actually use to make a decision.