What’s Wrong With Your Estimates (and How to Improve Them)

If you often fail your estimates — this is how to estimate the tasks quickly and accurately.

Photo by Headway on Unsplash

Every more or less significant project has its stakeholders. And the stakeholders always want you to give the estimates.

Imagine that you are the CEO of the building company and your customers ask you to construct a building. But they want you to estimate it first. They want to know if the target is achievable with the given time and budget constraints. Here are the examples of what you should estimate:

1. How many investments do you need to raise?
2. How much time does the whole project take?
3. How much money will you pay to your subcontractors?
4. What is the amount of materials needed?
5. How many people will accommodate?
6. How much time the building will exist?

In the beginning, you never have the answers to these questions. And these answers are also of interest to yourself, your customer, subcontractors, employees, future residents, and city authorities.

You can find out the exact answers to some of these questions only by building the house to the end. And to the rest of them — even after a certain time has passed.

The same is true in software development. The only difference is that we need to evaluate tasks much more often. Agile methodologies require us to have a short planning horizon, which means regular estimates.

Who needs software estimates?

Customer

For the customers, an estimate is a price. They can prioritize the features by comparing their business values with their estimates.

Project Manager

For the PMs estimates are the planning tool. With the help of estimates, he can understand the deadlines, calculate the budget, and form a team.

Dev team

For the development team, an estimate is a measure by which they can express the amount and complexity of the work they have to do. They can measure their efficiency, knowing if they are efficient enough.

The main difficulty of estimation

Okay, what’s the problem then? Why is the topic of estimations raised so often, and why are there so many implementation approaches?

The enemy we are trying to overcome is the Unknown.

I bet you have witnessed how a task estimated in four days cannot be implemented even in several weeks. And sometimes a monstrous bug that threatens to break the entire architecture of the application and is rated “just in case” a week is eventually successfully made by a newcomer in a couple of hours without any consequences.

Why is this happening? Because reality doesn’t match our expectations. And this is not because someone is inattentive or inexperienced. This happens because the estimate was made on the basis of incomplete information. This usually happens when too little effort was devoted to the analysis stage or, which is much more common, the team simply was not ready to do the estimate.

The estimation rules

I have derived the following rules to start estimation, and I never estimate unless all of them are met:

1. Requirements are ready and complete — do not evaluate requirements that you do not see, they are not completed, or you know for sure that they will be changed.
2. Estimate only what you know how exactly it will be done. If you don’t know how you will perform certain functionality, you won’t be able to evaluate it qualitatively. Analyze, plan and start estimation in the end.
3. The smaller the task that is estimated — the better. Do not try to estimate a task so large that it cannot easily fit in your head. Always divide it and estimate its parts.
4. An estimation framework is used. The estimation process should be known to the whole team from the very beginning. Decide on the units of measurement, methods, and approaches that you will use. Determine the framework that works best for your team and stick to it.

Units of measurement

Most likely you have heard that estimates are usually made either in hours or in arbitrary units (for example, in story points).

I hope everything looks clear with the hours.

Meanwhile, story point (SP) is a value that we do not deal with in everyday life. It is not part of Scrum, and most teams perceive it simply intuitively. Often, converting it in the head to the hours is a common mistake.

Let’s figure out what the story points stand for:

1. Story Point — is a relative value. The same task can be estimated as 2 SP in the team and as 21 SP in the other one. And both can be right. The main thing is to have the same understanding of what lies behind 1 SP between all of the team members.
2. Story Point does not mean an amount of time needed to complete the task. It reflects task complexity, the amount of work and uncertainty. The bigger and more complex is the task, and the less we know about it — the more story points it costs.
3. Story points are a great measurement of a team’s velocity. In the beginning, you can assume how many story points your team is able to complete per 1 sprint (for example 45 SP). And then when the sprint is finished you can retrospectively look at whether you guessed or not, adjusting your velocity value for the next sprint. In a few sprints, you will get to the value pretty close to real one. This will help you to define your team’s sprint scope more accurately.
4. It is nice to have a numeration system when during estimations. For example, the most popular one is the “Fibonacci system” where for the estimates you can use only one of the following values 1, 2, 3, 5, 8, 13, 21, etc. Systems like this one will help you to avoid wasting time on doubts about whether this task is 9 SP or 10 SP.

Estimation Techniques

OK, we are ready to start estimating our tasks. But how is it done?

There are dozens of estimation techniques, but I will pick out for you those that I use for myself and they have proven their usefulness and effectiveness in practice.

Delphi method

This method is based on estimations of several experts.

First, each of them estimates the item individually in isolation. And then all the estimates are compared.

If there are discrepancies in the estimates (and they usually exist, and this is good), then they are publicly discussed. After the discussion, another such round is held. And so on in a circle until an agreement is reached in a single estimate.

The number of rounds is limited and negotiated at the very beginning. If the limit of rounds is reached and there is still no agreement in a single estimate, then you need to look at all the estimates.

Usually, if the differences are small, then a larger estimate is taken.

If the spread is significant, then the team is not ready to give an estimate (for example, it does not have enough information). Collect the necessary information and, when ready, start from the beginning.

Estimation by analogy

This technique is one of the fastest. And in the presence of a certain history of estimates and experience, it is also very accurate.

The most similar completed task in the past is taken as the basis. In order to determine the maximum “similarity”, you need to consider how similar the following factors are:

1. Task size;
2. Task complexity;
3. The composition of the team that performed it;
4. Dependencies (internal and external);
5. Uncertainty.

Find an analogy. Define the difference. Adjust your score by the difference.

Please note that this technique works the worse, the fewer similarities the tasks have. If you determined that the difference between the estimated task and its analogy is quite large, it is better to refuse to use this method. In other cases, feel free to use it as the fastest and the most accurate.

WBS (Work Breakdown Structure)

The technique here is to decompose our task into atomic subtasks, each of which can be easily estimated.

To what extent should tasks be decomposed? Usually, this line is felt when each task is quite easy to evaluate and in each of them, all the steps necessary to complete it are obvious.

If there is a task for which the steps are not obvious, we split it up. If we can’t evaluate any of the tasks, we split it up. Our goal is to get a set of small estimates.

Please note that the estimate of the resulting problem will not be a simple sum of the estimates of its components. You must adjust the final result, taking into account dependencies between subtasks, risks and uncertainty.

What technique to choose?

To select the most appropriate method, I usually use the following scheme, consisting of 3 questions:

1. Have we ever done a similar task in the past? -> Analogy
2. Do you know all the steps to complete this task? -> Delphi
3. Can you estimate the subtasks it consists of? -> WBS + Delphi

Did you answer “No” to the previous 3 questions? You probably don’t have enough information. Collect it if possible, and if it is still not enough — try to give a “rough” estimate using all of the above methods separately and give a final estimate in the form of an interval (for example, 13–21 SP).

Remember, that estimates are just the tool. They are needed to simplify the planning of work that should be done.

It’s always better to give a rough estimate and start implementing than to waste time estimating accurately but not starting the implementation itself.

👋🏻 Thank you for your reading. I hope this article inspired you to improve your estimation process. If you implement at least one of the above advices in your project you will notice its pleasant effect immediately.