Why Is It So Hard To Provide Accurate Estimates?
If there is one thing that we software developers are infamous for, it is our inability to estimate our work accurately.
The problem is so commonplace that many project managers consider it best practice to multiply developer estimates by a factor of two — at least.
Whether you are a software developer or not doesn’t matter; if you have been in the vicinity of a software project, you probably know what I am talking about.
Why has it come to this? Why is the simple question “how long will it take to build this?” so hard to answer?
Apart from the fact that we are trying to predict the future, the answer is that the act of estimating is complex yet deceivingly simple, especially when we bite off more than we can chew.
The larger the task, the more prone we are to be overoptimistic. We overlook potential risks, neglect steps necessary to finish, and ignore delays incurred by others involved in the process.
And — worst of all — we tend to overestimate how much we learn from previous estimates.
The Art of Navigating a World of Uncertainties
Whether we are in an agile environment or not, we typically estimate tasks in bulk during group meetings. The good thing about this is that we get multiple perspectives, but there are also drawbacks.
For instance, the amount of time available to spend on each item on the list is limited. This time constraint means that we cannot afford the luxury of leaving no stone unturned for each and every task. Instead, the process relies on gut feeling and discussion.
While these assessments (hopefully) rely on past experience, we will make subconscious assumptions. We might take certain things for granted, or we neglect to factor in all the unknowns. Yes, even if we are seniors with 25+ years of experience.
Another factor is skillset and experience variability. What if the people that end up doing the work aren’t the ones providing the estimates?