Software Estimates are not the Invention of Satan

Estimates seem to be the bane of software developers, many of whom would say that estimates are nothing but a waste of time.

By observation, estimates are often misunderstood and misused. Developers and development managers in particular often resist providing a completion date, even with conditions, because they know that as soon as most people in marketing or finance hear a date, the only thing they will remember is the date and none of the conditions. The date will become a cudgel used to beat them from now until eternity.

A great majority of developers with more than three years in the field will have experienced this ridiculous situation, and their take away is that the only reason that someone wants a date is to cast blame and dispersion when the date is missed, and it is almost always missed.

The reality of the previous scenario should not, however, relegate estimates to irrelevance. It's important to remember that as a developer you request estimates from people that provide you services as well. Whether you're getting your fiber hook up at home or getting your A/C repaired, you're going to ask when the tech is going to arrive, how long they will be there, and how much it's going to cost, all of which require estimates.

You might balk that these sorts of estimates are different, because they're repeated, I've never seen a software team that didn't ask estimation questions of each other. QA wants to know when features will be ready for testing, the front end team wants to know when an APIs will be live, and developers will often want to know when a teammate expects to push a change.

All of which stems from the need for everyone to plan their own activities. Maybe you don't want to start on some in depth code if you're going to have to pause in a couple of hours to work with a teammate integrating their latest change.

This need to plan doesn't stop with the development team, everyone needs to plan their work, and to do so they need information and they often understand that the information will be speculative. Additionally, in many modern businesses, the foundational source of business value emerges from the technology department with many value layers applied later.

This can make the tech department a bottleneck in the value chain, which is the actual source of the problem with the initial scenario.

To alleviate the bottleneck crisis, or, better, avoid it altogether, it's important to focus on incremental value delivery that's enabled by iterative development and continuous delivery. Additionally, it's important for the tech departments to have an understanding of other business goals so that they can align their deliverables with those goals.

When product can successfully orchestrate continuous value delivery that's aligned with the goals of the business, communication and estimates are both improved and collaboration becomes much better.