Intro to estimation

Estimation is an important part of software development. It helps us understand the number of resources needed to complete a task, and it helps us plan which tasks should be done first. Estimations can also help us improve efficiency by allowing us to allocate resources in the most effective way.

Hour glass on stone
Photo by Aron Visuals / Unsplash

This article goes into detail about what estimation is and why it is important.

What is an estimation?

Estimation is an approximate value in cases where the exact value cannot be determined with certainty using measuring or calculation. The estimation is an approximated value due to the less-than-perfect information used. Perfect information would allow us to measure or calculate. Every estimate results in three values: The expected value, the accuracy of the expected value, and the precisenesses of that value.

Examples:

  • I estimate you are working between 9h00 and 16h00. The accuracy is 56.4% (assuming 60% has a job and 94% of those are day jobs) and the precision is between 0 and 7 hours (the estimate is still accurate if your work starts at 8h00 or ends at 19h00).
  • I estimate your assigned gender at birth is male. The accuracy is 52.5% (based on the worldwide average) and the precision is binary (either true or false).

Both estimations could be improved by improving the information we have. Since my article targets a specific audience (those employed in the field of software development) there is a good chance that you are male and employed (due to averages). So I’m confident that both the accuracy is a lot higher

If we are in the same room I wouldn’t need to estimate since I can measure it. In that situation my information is perfect and thus I do not need estimations assuming my observation is perfect.

An estimation *always* comes with a degree of uncertainty, and the accuracy of the estimation depends on the quality of the underlying information.

Less-than-complete information is due to complexity, future events, or because obtaining all details is too costly. The information’s quality determines the estimated value's accuracy and precision. And thus the estimation always contains two kinds of information: The value we expect to measure, the likelihood that we are correct (accuracy), and the margin (precision).

graph, x-axis: value, y-axis: probability density. There is a ball curve that shows that width can be considered precision, while the distance between the heighest point and the reference value describes accuracy

When estimating we need to take into account the concept of accuracy and precision. Accuracy describes the distance toward the target, while precision describes the size of the target. Hitting the target every time makes you accurate. But hitting a small target requires precision.

It will be accurate to say that someone's age is between 0-200 years, but that is also very imprecise. While saying that someone is exactly 1.135.296.000 seconds old is very precise, but also very likely to be inaccurate, only a single second needs to off and the estimation is wrong.

Why estimate at all?

Achieving a goal requires effort. And even if all routes lead to Rome, some are better than others. The best way to do this is to plan so that resources (time, money, people) are available when needed and so that the right actions can be taken at the right time.

To plan, we need to have an idea of the resources (time, money, people) needed to complete a task. This is where estimations come in. Estimations inform us how to allocate resources, and which potential risks we might encounter.

Executing a plan requires resources, estimations inform us of the number of resources before we start executing.

Performing without a plan or estimations can still yield results. But it doesn’t reveal to us what we need, how to schedule our tasks and any risk will be considered a surprise.

An estimation can reveal that we don’t have enough resources, or that a specific resource is not available at a given time. Knowing this the plan can then be modified so that any additional cost can be reduced. Another important aspect is that additional cost is taken into account beforehand.

Estimations prevent surprises

In the end, estimations have the same purpose as the actual values: To make informed decisions about acquiring a goal. Decisions are not only a go or no-go. But also whether it might be more effective to delay a project by a week or to allocate more resources.

Estimations are used to drive and justify decisions

If estimations are unfavorable we can improve the effectiveness of the plan by changing the order or allocating more resources. By spending extra resources we can reduce resources we need elsewhere (for example: spending money to buy a tool instead of spending time to create a tool). All of this is to improve the chance of success.

Estimations help us to improve efficiency.

When estimations are shared with others they can review the estimated values. They might have a more complete understanding of a certain subject and thus can improve precisions and accuracy.

Estimations can communicate knowledge and skills

A plan with estimations can be used to coordinate the use of limited resources. Or if a resource will not be available, another resource or another plan can be proposed.

Estimations prevent resource conflicts

Accountability & Responsibility

This might sound weird, but as a developer, nothing makes me happier than being accountable and responsible. Because being accountable is all about having proof in numeric values, while responsibility is about responding to the outcome.

Developers should take “into account” the circumstances, meaning that when they are “held accountable” they should be able to explain in what way they are “responsible”. This is a two-way street that the manager should fear more than the developer.

Nothing is more effective than delivering a statement as “Unable to deliver on time due to requirements missing, resulting in additional work that was not expected.”

And nothing is more relaxing than stating the obvious as “Unable to deliver on time due to unfamiliarity with the environment. I requested time to improve my understanding of the framework we use but this request was denied.”

The text “unable to deliver on time” is synonymous with “the estimation was wrong”. Frankly the only time I think the developer is at fault is when the developer fails to communicate or when the developer is not putting in the effort, or when the developer purposely ignores agreements.

So if you are a developer who is constantly fixing bugs and not delivering a feature you might consider estimation. It’s the easiest to get an “account” of what goes wrong. And if the manager asks you to stop estimating you can simply ask: “Would eliminating estimations improve our performance? Because all it does is make problem areas visible, nothing more.”

Accountability and responsibility are organizational tools, not a tool to manage people.

Conclusion

I hope the above improves the understanding of estimations, their impact, and their value. The next article will describe various techniques for estimations and how to apply them effectively. I will also address what some people get wrong about #NoEstimate although that might be covered more in detail in the final article which will include estimating the unknown.