Why Rely on Estimations?

One of the most common questions developers get asked is, ‘How long does it take?’ Building this new feature, fixing that annoying bug, or migrating a legacy application. Everything has a price, of course, and managers need to weigh cost against benefits. Most developers dread this question and don’t like giving estimations. Why? Because the odds are high, that their guess is completely wrong.

Giving estimations for software projects is a bit like speculating on future stock prices, predicting weather conditions or betting on horses. It’s a mix of randomness and assumed causality. Add a large portion of unknown factors to this, and you get the perfect conditions for uncertainty. Once your project’s complexity goes beyond a hello-world program, relying on estimations becomes very risky.

Nonetheless, it is still frequently expected of software developers to give estimations. Often, there is an expectation to adhere to these estimations in the course of future events. Project conditions, domain and technical knowledge may change completely, but developers are still judged by the accuracy of their original estimations.

While the agile movement brought some conceptual changes to the estimation game, the core of it has not changed. It doesn’t really matter if you estimate in time units, story points or t-shirt sizes. The underlying assumption is still that humans can overlook a complex topic like a software project and give somewhat reliable guesses on the required effort.

Here are some examples of why estimations tend to fail completely:

• Requirements are unclear, incomplete or changing
• Knowledge and skills of team members are different, people are joining or leaving the project
• Teams are interrupted by urgent topics, thereby decreasing efficiency due to context switching
• Testing uncovers hidden bugs or misunderstood requirements which needs fixing effort
• Architecture or tool decisions turn out to be problematic, changing them requires extra effort
• Progress depends on external conditions like auditors, consultants, infrastructure downtime, other teams etc.

This bears the question of what to do instead of estimations. Unfortunately, there is no perfect way to solve the planning fallacy. I will give you some advice from my personal experience in one of the next posts.

Until then, I am curious to know about your experience with estimations in software projects. Is there a reliable way to deal with the all too-common uncertainty? Feel free to let me know.

#SoftwareEngineering #Estimations #ITProjects #Uncertainty