5 Reasons Software Estimates Go Wrong (and What I Do Instead)

Anas Abdullah — Mon, 02 Nov 2026 13:13:08 +0000

I've been on both sides of "how long will this take?": first as the developer giving the answer, now as the technical project manager turning that answer into a plan a client can trust.

Estimates rarely fail randomly. They fail for the same five reasons, over and over.

1. The task is too big to estimate

"Build the checkout" can't be estimated well. "Cart summary screen", "payment provider integration", and "order confirmation email" can.

What I do: break the work down until no single piece is more than a few days. If it's bigger, it's hiding something.

2. Only coding is counted

Code review, QA, bug fixing, deployment, documentation, and client clarifications are all real work. Three days of coding can easily become five days of delivered work.

What I do: add explicit rows for "the work people forget" in every estimate, so they can't be left out.

3. Unknowns are treated as knowns

A new third-party API or a vague requirement gets the same confident number as a CRUD screen.

What I do: estimate in ranges. Ask for optimistic, most likely, and pessimistic values, and combine them with PERT:

PERT = (O + 4M + P) / 6

A task that's 3 days at best, 5 most likely, and 15 if things go wrong comes out at about 6.3 days, not 5. For real unknowns, run a short time-boxed spike first, or add a visible buffer tied to that specific risk.

4. The estimate becomes a promise

An estimate given under pressure in a meeting quietly turns into a deadline.

What I do: share a range or a date with a confidence level, name the assumptions behind it, and say when it will be revisited. Uncertainty explained up front is a conversation; a surprise later is a broken promise.

5. Nobody updates it

The plan changes; the estimate doesn't.

What I do: track estimated vs actual effort on every task. Not to blame anyone, but to learn which kinds of work the team keeps underestimating.

A note on AI coding tools

It's tempting to cut estimates because "AI will make it faster". AI can shorten the coding part, but it doesn't remove review, testing, or integration, and more generated code can mean more to review. I don't apply a blanket AI discount; I adjust from the team's own actuals.

The full process and a free template

I wrote up the full seven-step process, with estimation techniques compared and the formulas explained, here: Software Development Estimation: My 7 Steps.

There's also a free Excel estimation template that does the PERT math, keeps risk buffers visible, and gives you an estimate at about 84% and 95% confidence. No sign-up, and it works in Google Sheets too.

How does your team handle estimates? I'd like to hear what works for you.

DEV Community: Anas Abdullah