The product owner asked, “How long will this take?”
The developer answered, “Three days.”
It took three weeks.
The senior developer asked, “Was your estimate wrong?”
“Yes.”
“Was the work wrong?”
“No.”
“Then what was being measured?”
Sitting with the Koan
Every developer has lived this koan. The estimate was wrong. The work was not. And yet the project review will almost certainly focus on the gap between three days and three weeks, rather than on what was actually built.
The senior developer’s final question is not an accusation. It is an invitation to look more carefully at what an estimate actually is, and what we pretend it is.
An estimate is a guess dressed in the language of certainty. When a product owner asks “how long will this take,” they are often asking something closer to “can you make me feel safe about this?” And when a developer answers “three days,” they are often doing the same thing in reverse — reaching for a number that feels reasonable in the moment, that won’t cause alarm, that reflects how long the work should take in a world without interruptions, misunderstandings, scope creep, or the unexpected dependency discovered on day two.
The work, meanwhile, is honest. It takes as long as it takes. It does not negotiate. It does not round down.
So what was being measured? Not the work. The estimate was measuring the developer’s imagination of the work — a mental model built before the problem was fully understood, before the legacy code was read, before the third requirement was added quietly in a Tuesday standup. The estimate was a portrait of a task that did not yet exist.
This is not a failure of skill. It is a failure of category. We treat estimates as predictions when they are, at best, approximations. We treat them as commitments when they are, at most, hypotheses. The gap between three days and three weeks is not evidence that the developer was careless or the work was mismanaged. It is evidence that software development is a process of discovery, and discovery does not run on a schedule.
The koan does not tell us to stop estimating. Teams need to plan, and planning requires some shared understanding of scale and sequence. But it asks us to be honest about what we are doing when we give a number. We are not measuring the future. We are describing our current understanding of a problem we have not yet solved.
The practice, then, is humility at the keyboard. Give the estimate. Note that it is a guess. Return to it when you know more. And when it turns out to be wrong — as it often will — ask not “why was I wrong?” but “what did I learn that I did not know before?”
The work was not wrong. The work was the teacher.