Software engineering

We will look at two commonly known types of estimation, and for the purposes of this article, I will name them:

• absolute estimation

• relative estimation

Absolute estimation

This type of estimation involves determining how long something will take in hours (or days). For example, adding product rating functionality will take 20 hours. Upon completing this task, it is clear how much time was spent and whether it was completed within that time.

This type of estimation works well for work planning and allows for high-level planning of when we can deliver something. It is important here to break down tasks to be estimated into as small as possible. Breaking down requests into smaller pieces helps you understand them better, and as a result, the estimate can be more accurate.

We can also establish a scale by which we estimate tasks:

• Small tasks: 4h

• Medium: 8h

• Large: 16h

When estimating, we use this scale and do not consider whether something will take 5 or 6 hours but rather try to fit it into one of the options: small (4h) or medium (8h).

Relative estimation

In this case, we do not estimate in hours or days but use a different measure, such as:

• Fibonacci sequence (numbers 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89)

• T-shirt sizes (XXS, xs, s, m, l, xl, XXL)

• Powers of 2 (0, 1, 2, 4, 8, 16, 32, 64)

This type of estimation works well for all kinds of refinements where the whole team estimates tasks. The beginnings can be difficult, and the estimations are scattered, but over time the team synchronizes, and the estimations are more accurate.

Accurate estimations

If you ask someone about the time needed to complete a task and that person answers “I don’t know”, a warning light may go off in your head, but dear reader, only calmness can save us. To estimate something, you must first understand it. In 99% of cases, tasks are incomprehensible because they are poorly defined, have unclear acceptance criteria, or have too many unknowns about how to accomplish them.

Time is needed to define the task so that it is understandable to the whole team, and then you can ask for an estimation again.

What is estimation

Estimation is not a promise or a declaration of a deadline. Estimation is a probability distribution of completing a task within the planned time. Sometimes things may be quicker, and sometimes they may take longer. Everything is fine as long as you believe in it and see that the estimates are made honestly.

Estimation is an honest estimate. What is the chance of completing this task in one day? You may hear the answer that it is low, or in percentage terms: 5%.

When you ask what is the chance of completing the task in a week, you will probably get a different answer, for example, 90%.

Summary

In my opinion, both types of estimation are both appropriate and inappropriate. Why? Because everything depends on the work of specific teams and cooperation between the engineering team and the product owner (or project manager). It is NOT about the type of estimation but about the way it is done. If the estimations are reliable, then nobody will cry over their exceeding. Problems arise at work, and sometimes something can be underestimated, but it is all acceptable when we work reliably and trust each other.

If you work in a team or organization that requires you to confess to every additional hour spent on a task “in front of the boss” (even though you made the estimation honestly and as best as possible), consider whether this is the right place for you.

Estimate without fear.