The manager asks how long the feature will take. The engineer says three weeks. The manager says they need it in two. The engineer agrees.
Neither number was derived from analysis. Both were opening positions in a negotiation.
The actual work will take however long it takes, independent of the number spoken in the room. The estimate is not engineering. It is bargaining.
⸻
The Precision Illusion
Story points, T-shirt sizes, Fibonacci sequences. The industry has built an elaborate vocabulary around estimation, and all of it is designed to create an illusion of engineering rigor around what is fundamentally a guess.
No one can predict how long it takes to solve a problem they have not solved before. That is the definition of problem-solving. If the work were predictable, it would be execution, not engineering.
The estimate pretends that the unknown is known. The system rewards this pretense, because a number, any number, can be placed on a roadmap. Uncertainty cannot.
⸻
The Anchoring Effect
Once an estimate is spoken, it becomes an anchor. The team calibrates against it. The manager builds the project plan around it. The stakeholder communicates the date externally.
When the work takes longer than the estimate, the conversation shifts from "What is the right solution?" to "Why are we behind schedule?" The estimate, which was always a guess, has become a commitment. The engineer is now defending their performance against a number they fabricated under social pressure.
The system penalizes the honest estimate. The engineer who says "I do not know, I need to investigate" is seen as unprepared. The engineer who says "two weeks" is seen as decisive. The former is accurate. The latter is performing.
⸻
The Velocity Treadmill
Agile methodologies compound the problem. Teams track velocity, the number of story points completed per sprint. Once a baseline is established, the expectation is that velocity remains constant or increases.
But velocity is a lagging measure of past performance, not a leading measure of future capacity. A team that completed 40 points last sprint may encounter a different class of problem this sprint. The physics changed. The metric did not.
When the team misses their velocity target, the retrospective does not ask "Was the problem harder?" It asks "What slowed us down?" The premise is that the pace should be constant. The reality is that engineering work is inherently variable.
⸻
The Honest Frame
If you must estimate, estimate in ranges. Best case, worst case, and the conditions that determine which one you hit.
Name the unknowns explicitly. "This estimate assumes the API specification is stable. If it changes, add two weeks." This is not hedging. It is honest engineering.
The system wants a number. Give it a range and a set of conditions. If the system cannot tolerate ranges, it is optimizing for predictability at the expense of accuracy. That tradeoff should be named out loud, by someone.
End.