Dramatically Improving Your Estimates

If you work in the software industry you already know that quite well, but if not, believe me, there are a few things that make a team more uncomfortable than have to estimate tasks or entire initiatives.

Human beings are largely recognized to be very poor at estimating things, we suffer from many types of cognitive bias and we are easy to influence depending on the level of pressure we are subjected to.

When someone or a team is asked to estimate a task or an initiative many questions come to their minds like:

• How this information will be used?
• What are the expectations behind this initiative?
• What will happen if I fail to deliver according to the estimate?

Why estimate software is so hard?

Although we are often unsuccessful in estimating software, there are two main reasons for our notorious aversion:

1. Estimating software is very hard. It is no wonder that we have been struggling for at least 40 years to do a better job on estimating software since Allan Albrecht defined Function Points in 1979. Since then, many methods have emerged like COCOMO, Use Case Points, and Story Points but our ability to estimate has not improved at all, so something tells me that the problem is not the method.
2. Most of the time estimates only have value if provided at the very beginning of the project, as John Fisher from Atomic Objects likes to call it (the “point of maximum ignorance”). As time passes we acquire much more knowledge about the initiative and our ability to give a more accurate estimate increases, but the value of providing an estimate diminishes proportionally.

Should we give up on estimation?

Of course not. You can imagine how difficult would be to plan an initiative if you have no idea of roughly when it is going to be finished. But more important than that, the simple act to get the team together to estimate something brings the following benefits among others:

• Promotes conversations about the tasks that lead to a better understanding of the task and initiative.
• Help to identify gaps earlier in the process and fix them before starting the project.
• Forces the team to break big tasks into smaller items, mitigating risks and delivering faster.

To be honest, many of us cannot afford not to give estimates to colleagues and stakeholders.

How to dramatically improve our estimates

Although I will be presenting techniques to get to better estimates, bear in mind that, whatever your reason to estimate something, you should focus on providing a responsible range and not an absolute number. A responsible range means that the initiative would be considered a success if any number in the provided range is achieved.

That said, let’s first examine what are the sources of work in a software initiative. The chart below presents the four main sources of work.

1. Management Zone is the most common source of work and it represents the work you know that must be done. Unfortunately, many teams count only on this source of work when giving an estimate. Very often these tasks are already placed in a backlog or are very straightforward to identify. The strategy here is to understand the work involved and estimate accordingly. In the agile world, the refinement meeting is the place to deal with this kind of work.
2. Risk Zone is another well-known source of work, many of us already built a risk map to identify the risks and quantify the probability and impact of each risk. Based on this risk assessment you can identify more work to deal with the risks and have a better estimate at the end. Two interesting approaches to apply here are Risk Storming and the Agile Approach To Dealing With Uncertainty.
3. Research Zone is a source of work that is forgotten very often when estimating software. It represents the work that you know that will be necessary at some point in the initiative its effort cannot be estimated at the moment or it is too early to get into the details. Usually, the team needs to work on PoCs or Spikes to understand the level of effort that those tasks will require. On strategy to not forget those tasks, is to create ballparks, estimate them, and break down the ballparks into small tasks later in the initiative.
4. Reactive Zone is by far the most hidden source of work. The additional effort required to deal with this work is completely unknown and will end up appearing later in the development time. The approach here would be using your historical data and see the average extra effort the team has been adding latter to the projects and consider it as a contingency reserve.

Conclusion

By considering these 4 sources of work in your next initiative estimate, your team will not only be more accurate and predictable but also more realistic. Better estimates lead to less pressure from the stakeholders, more happiness for the development team, and lastly more product quality which translates to happy customers.