Estimates, that great devil that sneaks into our day to day and marks us. Some of the questions that most people who are starting in the Agile world have asked me are "how do you estimate in Agile?" or "how do you do to tell the customer how long it will take?".

In Agile, the estimation phase has matured. We start from the fact that the software is complex and, therefore, there is uncertainty. It is impossible to know what will happen. Software professionals discover it project after project. It is something that only experience can tell us.

Let's review the different estimation techniques and see a small analysis of each of them to better understand this phase of Agile.

1 Estimation in hours

The estimate based on hours is the most common. Basically it is to indicate the time that we are going to take in carrying out a task. With the estimate in hours we usually make several mistakes. The first thing we commit is that they ask us for a time estimate and... we give some time!

Let's give an example, imagine that they ask you "how long do you take to go from Madrid to Barcelona by car?". The first thing we do is think and quickly say "about 6 hours".

Imagine that now they say "Perfect! Well, you leave tomorrow, Friday at 2:00 p.m., with 2 babies in the car, with a Renault 5 and without being able to use tolls". Typically, our reaction is the following: "No! With those conditions it would be more time".

We see this particular case very often, we estimate a time based on an idea without knowing the risks associated with the task. Normally we solve it with the so-called "mattressing".

The "mattressing" is to make the following reflection: "We have estimated this project in 1,000 hours, we are going to say 1,300 in case something happens".

The problem of the "mattress" is that it is not transparent, it is not honest, deep down you are cheating. This type of practice occurs because, many times, we focus on negotiating instead of producing software with value.

In the traditional world, this is solved with the Risk Plan, which includes everything we believe could happen and the cost that it would entail if it occurred. In this way we try to make as few mistakes as possible.

The problem of estimating in hours with a Risk Plan is that, in complex environments where it is not possible to predict what is going to happen, it does not work. Unfortunately, for us, the software is complex and in these environments the only way to work is "try-feel-respond".

2 Estimation in points or "history points"

A "story point" represents a quantity of work that we have to perform. There are teams that confuse the technique of estimation by hours and the estimation in points because they associate time with points: "a point is a day of work". Obviously, if we make that analogy we are really estimating in time.

Let's see it through an example. Imagine that we have to paint a room of 100 square meters. An expert painter, who paints 50 meters a day, will take much less than a painter who does 10 meters a day. But for both, it's the same job! In this example, 1 square meter would be 1 point. This is the advantage of point system, it is easier to reach a consensus as a team.

The point estimate is a relative estimate. This means that tasks are estimated by comparing them with those already estimated. If we say that a task is 3 points with respect to another of 1 point, what we are transmitting is that it will take 3 times more work.

The planning poker technique is used to estimate points. It is very useful because it allows us to have conversations about how to do the backlog items.

The best advice I can give for the estimation in points, is that they are only estimated at the level of User History or Product Backlog Item.

The ideal is that we take an item and divide it into the tasks that we believe we must do. Then, together, we estimate the total work of that item, even though each one of us does a part.

3 Estimate in sizes

Given that many teams have difficulty spending hours on points because they end up associating time with the points, there is an intermediate technique: associate T-shirt sizes with the backlog items: XS, S, M, L, XL.

Since you cannot compare some sizes with others at the numerical level, there are those who count the sizes afterwards. Each size is associated with a number following the Fibonacci series. Once the team matures, it's time to switch to the points system.

There is something that we cannot lose sight of in this technique. If an item is marked with a certain size, the same item (after time) must be marked with the same size, although now we have more expertise.

The reason is the same as with the example of the painter, the room will always be the same, regardless of whether we paint faster now.

4 Estimation in PBIs

Here comes the star estimate! A long time ago we learned this technique through Jerónimo Palacios and it is the most scientific bet. Remember that Scrum is based on empiricism: as we gain experience, we can gain in predictability.

The estimation technique in PBIs measures the amount of Product Backlog Items (PBIs) that we are capable of doing in a Sprint. The first thing we tend to think about is it depends on the size of each GDP!

Imagine that all the PBIs had a similar size, this technique would be ideal, it would tell us with an interval our ability to work in a Sprint.

For example, after several Sprints we can ensure that our team makes [7-11] PBIs per Sprint. With this data our Product Owner can make projections about the future of the product.

Let's go to the worst case: all the PBIs are different. What will happen is that our speed would be measured in a much larger interval, for example [4-14] PBIs by Sprint. In this case we are much less predictable.

If we want to improve our predictability, our Product Owner will have to focus on grouping small PBIs and dividing large ones to achieve that homogeneity (and thus improving the data).

Here is the key! Our Product Owner should determine how predictable he or she wants to be. If you want to be more reliable you will have to homogenize. Many may think "if my team has been doing between [7-11] PBIs and suddenly the Product Owner introduces very large PBIs, the team will not give them time".

Remember that in Scrum estimates are made and are not commitments. If suddenly we are asked for very large PBIs, what will happen is that this Sprint will be less than anticipated and our data will be updated to the new reality.

The great advantage of this method is that it prevents us from "throwing ourselves into the abyss" without writing a line of code. Being a method based on experience, you need Sprints to start running.

Really the points and the hours too, but it is more probable that we give data too soon and that we generate frustration when not fulfilling it.

Conclusion

The conclusion we can draw is simple: you can estimate, but use the estimate as an indicator of happiness in which if you meet what you said you get a reward and, otherwise, punishment if it does not work. Estimating is good for many things, but not to grade the success of a project. What's more, you can fulfil your estimate and still nobody wants the software.

We can say that estimates are important in controlled environments. In complex environments investing a lot of time estimating things that are going to change, that are not defined or that we do not know, generates a lot of unhappiness. Let's focus on taking product and, more than estimating, let's use our experience and not our imagination.