Estimates move for five common reasons. Three of them are legitimate and mean the project is being run honestly. Two of them mean something is wrong. The difference is usually visible in how the reason is described, not in the reason itself.
Before going through them, one thing is worth accepting: software estimates are genuinely bad, everywhere, including at companies with excellent engineers. The work involves discovering things that could not be known in advance. A team that never moves an estimate is either padding heavily or not telling you about the discoveries.
Key takeaways
- Moving estimates are normal: Never-moving estimates are the suspicious case.
- Three legitimate reasons, two bad ones: Discovery, changed requirements and interruption versus vagueness and rework.
- Specificity is the test: A real reason has a name, a date and a consequence.
- Watch convergence, not accuracy: An estimate that narrows is healthy. One that keeps resetting is not.
The three legitimate reasons
Discovery
Something turned out to be different from what the documentation, the data, or your own team said. An integration does not support a case you assumed, a data set is dirtier than expected, or a rule in your business was never written down.
This is the most common cause of real slippage, and it is a sign of a team actually doing the work rather than guessing. A good version of this reason is specific: "the shipping provider's API does not return partial dispatch, so we have to model it ourselves, which is about a week."
Changed requirements
Someone asked for something different, or the original description meant two things and the team built the other one. This is usually the client's cost to carry, and it is fine, as long as it is named.
The failure mode here is silent absorption: a team that accepts changes without adjusting the date, then misses the date, then looks incompetent for reasons that were not theirs. If your team never says "that is a change", ask whether they are absorbing them.
Interruption
The developers were pulled onto production issues, support escalations, or another project. Nothing about the original work changed; there was simply less time spent on it than planned.
This is legitimate but it is also the most fixable, and it is worth tracking separately. If interruption is the reason two months running, your problem is not the estimate, it is that the team has no protected time.
The two that mean something is wrong
The work was never understood well enough to estimate
The sign is an estimate that resets rather than narrows. A team converging on a date says three weeks, then two weeks, then "Thursday". A team that never understood the task says three weeks, then three weeks, then three weeks, each time from today.
This is not dishonesty. It usually means the task was too large to estimate and was never broken down. The remedy is to break it into pieces small enough to finish in days, which also makes progress visible for the first time.
Work is being redone rather than finished
The same area is touched again and again. Each round is genuine effort, so each week's report is truthful, but the system does not advance. Causes vary: a design that did not hold, a requirement that keeps changing shape, or a piece of work being handed between people who each start over.
Ask what has been rewritten more than once and why. Repeated rework with no corresponding change in requirements is the reason to look harder.
How to tell them apart in one question
Ask: what specifically did you learn that changed the number?
A legitimate reason produces a specific answer with a name in it. A vague reason produces a category: complexity, unforeseen issues, technical debt. Those words are all real things, but used as an answer rather than an introduction to one, they indicate that the person speaking does not have a specific cause either.
The second useful question is whether the new estimate is for the same scope. Frequently it is not, and nobody has said so, which means you are comparing two different numbers and concluding something false about both.
For the wider picture of when moving dates indicate a stalled project, see how to tell if a project is really behind.
What to do about it
Ask for a range rather than a date, and ask what would have to be true for the shorter end. "Two to four weeks, two if the provider's sandbox works as documented" tells you the estimate and the risk in one sentence, and it gives the team somewhere honest to stand.
Then hold the scope rather than the date. A project that ships a smaller thing on time is almost always worth more than one that ships everything late, and the decision about which parts to drop is yours, not the team's.
Ali Boran Gazel