Most software engineering estimates are garbage.
That’s not because companies are using the wrong methods or tools. Work-breakdown structure or analogy-based? Mechanical or judgmental combination? Function, use case, or story points? SEER-SEM, WMFP, or Wideband Delphi? Fine.
The tools aren’t the problem. Rather, most estimates are garbage because they’re based on a fundamentally flawed understanding of how quality software is built.
The impact goes far beyond cost overruns and missed deadlines. The typical approach to estimates ends up forcing bad behavior while privileging vanity metrics over delivering actual business value.
Noise and non-determinism are inherent to software engineering
In Agile environments, estimates are often based on story points and velocity. How “complex” will it be to create a discrete piece of the solution? And how long does it typically take us to complete a story of that complexity? (I’ve written previously about how this approach to Agile corrupts Scrum with Waterfall methods of control.)