Your estimates keep coming back bigger. Here is what that actually means.
Estimate inflation is a symptom, not a negotiation. Four causes, how to tell them apart, and what each one costs to fix.
The short answer
When estimates grow for the same size of work, the cause is one of four things: the change touches more places than it should, nobody knows what the software currently does, the work includes a fix for something unrelated, or the team is padding against risk they cannot name. Each has a different fix, and only one of them is about the estimate.
A feature that would have taken three days last year now comes back at two weeks. The team has not got worse. The request has not got bigger. Something between the two changed, and the estimate is the first place you notice it.
Estimate inflation is a reading, not a position to negotiate down. Pushing back on the number without changing the cause gets you the same work, later, with a tired team. Here are the four causes, and how to tell which one you have.
Cause one: the change touches more places than it should
Ask where a change goes. If the answer names four files that all do nearly the same thing, the same logic was written four times, and every future change to it costs four times as much.
This is the most common cause and the most fixable. It also compounds: each duplicated path makes the next duplication likelier, because copying is faster than untangling under deadline.
- Tell: estimates scale with how central the change is, not how complex it is.
- Fix: consolidate the duplicated path once, as its own funded piece of work.
- Cost: days to weeks, once, against a tax you are currently paying on everything.
Cause two: nobody knows what it currently does
The estimate includes the time to find out. When the people who wrote something have left and there is no written description of the intended behaviour, every change starts with an investigation, and investigations are hard to size. So they get sized generously, which is the correct engineering response and a miserable commercial one.
You can confirm this quickly. Ask for the estimate broken into "working out what happens now" and "making the change". If the first half is larger, this is your cause.
Cause three: the estimate is carrying someone else’s debt
The team cannot make the change safely without first fixing something adjacent: a dependency two major versions behind, a test suite nobody trusts, a deployment that requires a person. So the fix rides along inside the feature estimate, unnamed, because naming it invites a conversation about why it was not done sooner.
This is worth surfacing rather than punishing. A team that hides remediation inside feature work is responding rationally to a budget that only funds features. Fund the remediation separately and the feature estimates drop on their own.
Cause four: risk nobody can name
Sometimes the padding is honest fear. An area of the system has broken twice, unpredictably, and nobody understands why. The estimate carries insurance against it happening a third time.
The fix is not a smaller number. It is a week spent making that area observable, so the fear becomes a known quantity. Teams are good at estimating things they can see.
Telling them apart
| Ask this | If the answer is | Cause |
|---|---|---|
| Where does this change go? | Several places that look similar | Duplication |
| How long to work out current behaviour? | Longer than the change itself | No description of intent |
| What has to be true before you can start? | An unrelated upgrade or fix | Carried debt |
| What is the worst case here? | Something vague about that area breaking | Unnamed risk |
What to do about it
- 1Ask for one estimate split into investigation, remediation and the change itself. The shape tells you the cause.
- 2Fund remediation as its own line rather than hiding it inside features.
- 3Fix the single most-touched duplicated path first. It has the highest return because everything else crosses it.
- 4Re-run the estimate on the same feature a month later. If it has not moved, the cause was not what you fixed.