How to Use Relative and Absolute Estimates in Agile Projects

When someone asks you for an estimate, I’m sure that your first reaction is to give an absolute answer, which means a concrete and absolute value. For instance, if someone asked you how long would it take you to run 10 kilometers, the answer would be something like, "I take 45 minutes to run 10 kilometers." Or if someone asks you how much you bench, you would say something like, "I can do 8 reps with 100 kilograms."

This kind of answer is so natural that it has become the way to provide estimates in the software development industry for the past several decades. The use of absolute vales, even for long-term estimates, has always been the preferred and only way to do it. This has to do with the sense of precision and security anchored to them. However, we are not that good at doing this kind of estimating, especially when size and/or complexity of what we’re estimating is somehow significant. Hard to believe? Keep reading.

Absolute estimates

In a 2006 study, Magne J?rgensen and Stein Grimstad of Simula Research Laboratories showed how bad we actually are with deriving absolute estimates. Based on a requirements specification to develop new software, they created several scenarios wherein they asked different groups to provide their estimates. The results were surprising — or maybe not.

Scenario 1: Size of the specifications

Setup: The same specification was given to two groups; both were asked to provide estimates. The first group received a one-page specification. The second group received the same specification, but it spanned seven pages.

Estimate results: The second group provided an estimate that was almost 50 percent bigger than that of the first group.

Scenario 2: Irrelevant information

Setup: The same specification was given to two groups; both were asked to provide estimates. The second group was given additional, irrelevant information, such as the software installed on the computers and the average age of users.

Estimate results: The second group provided an estimate that was almost twice as large as the one given by the first group.

Scenario 3: Anchored information

Setup: The same information was given to three groups. The first group (the control group) gave their estimates based on the specifications only. The second group was told that the customer, although having no idea what software development is, thinks the project will require around 50 hours. The third group was told exactly the same as the second group, except that the customer's estimate was 1,000 hours.

Estimate results: The first group estimated 456 hours. The second group (with the 50-hours limitation) estimated 99 hours (80 percent less than the first group), while the third group (with the 1,000 hours limitation) estimated 555 hours (20 percent more than the first group).

The results from this study show what the first agilists already knew (they made it very clear in the 2001 Agile Manifesto): Absolute estimates should be used mostly to size small and simple tasks. This is actually a key principle we are told in school. Decompose complex and big problems into smaller and simpler ones so that we can see the big picture clearly. For this reason, relative estimates are the right answer to solving several planning problems in IT, such as initial estimates. Instead of detailing and decomposing an entire backlog without knowing all the necessary details for the vast majority of the items, it’s simpler to analyze the items by comparing them.

This article is not meant to demonstrate my support of relative estimates, since enough information exists to allow anyone to understand their benefits. What I’m trying to show is that absolute and relative estimates are not mutually exclusive. In fact, they should be used together within each project.

It's not about relative estimates only!

Recently, I was approached by someone who told me she didn’t agree with the use of absolute estimates since they distorted the key goal of relative estimates, which is to hide the need to provide absolute data. While we were talking, it became clear that she didn’t understand the key benefits of relative estimates.

It is clear that humans are much better at providing estimates when they can compare two elements. We can easily and rigorously indicate how big (or small) something is when comparing it to another element instead of trying to do it in absolute terms, without any external reference. When you complete an exercise involving relative estimates, you establish a relationship of magnitude between each element. This relationship will prevail no matter what you do afterward. Replacing one of the estimated elements with an absolute value and letting it propagate to the other elements based on the established relationship not only makes sense but is actually necessary. After all, if you don’t do it, you will not be able to materialize that exercise into something concrete and you will not yield the expected benefits, such as a more concrete estimate in terms of the calendar (concrete/accurate is not the same as precise).

Let’s take a look at two concrete examples in a project.

Initial estimates from a backlog

Let’s assume a backlog in which the total number of items is equal to 220 points and that each iteration lasts two weeks.

Known-velocity scenario

Suppose that the team working on the project is the same and that both technology and architecture are also the same. The decision to use the velocity recorded during the previous project is wise. If the velocity is 20 points, this means that the backlog will be completed after 11 iterations (22 weeks). Because there’s data for velocity, there’s no need to have any additional estimates to determine the initial backlog.

Now let’s see what happens when you don’t have velocity information available.

Unknown-velocity scenario

If you have a scenario just like the previous one, but you don’t have any velocity data that you can use, you don’t have any other choice but to transform some of the estimated elements (relative estimates) into something more concrete. This, together with the team’s capacity (availability), allows you to come up with a more concrete initial estimate.

Choose one or two items from the backlog and split them into tasks (always make sure that no task is bigger than one day or eight hours). The total number of tasks will give the total estimate of the item in hours/days. From this point forward, it’s only a matter of applying the magnitude relationship built with the relative estimates to determine the initial estimate for the backlog. So if the chosen item (2 points) represents 22 hours of work, a one-point item would represent around 11 hours, whereas an eight-point item, which is four times bigger, would represent approximately 88 hours. The backlog identified in the previous scenario (220 points) would take an initial estimate of 2,420 hours of team work for completion.

You can clearly see how important it is to have relative estimates in this second situation. However, the need to use absolute estimates to decode the first elements of the estimates is also very clear. Actually, without this last step, it would not be possible to present any concrete estimate in terms of a time line (please note that I mentioned concrete estimate and not accurate or precise).

Iteration estimates

One of the key principles in Agile software development translates into coarse-grain estimates for high-level plans (e.g., release plans) and fine-grain estimates for low-level plans (e.g., iteration plans).

While planning an iteration, after all the details are known for the relevant items planned in the backlog, the team should split each item into tasks and provide absolute estimates for each (remember not to exceed one day or eight hours per task). This allows the team to understand whether it will be able to deliver the backlog items that were initially planned, while taking into account the team’s real capacity, which should be well known.

I’ve been also approached by people who do not agree with using absolute estimates while planning an iteration. They claim that the use of relative estimates, together with velocity data, is enough and that splitting items into tasks should be done only after the iteration has started and it’s ongoing.

Indeed, using velocity and relative estimates (points) may be an adequate approach. But practice has shown me that in almost 100 percent of situations, there’s always something that makes velocity change (such as a public holiday or someone going on vacation), making it almost impossible to use it for your current iteration for the team’s commitment. When you don’t have enough information to determine the amount of work to be done (as in future iterations), I agree and support the use of velocity data from previous iterations as an indicator (and to create pessimistic, optimistic, and normal scenarios). But for the current iteration, use the data that you have available (the team’s expected capacity) to determine whether the expected amount of work given by the total of estimated tasks can be completed.

This is why I don’t understand how a team can manage an iteration without having estimated tasks. How do you monitor your progress? What does the burn-down chart look like? When I asked this question, I was told that the iteration burn-down chart reflects the remaining points to be completed. The remaining work is updated when an item is done. I’ve immediately spotted two issues with this logic:

1. You can spend a few days without having any progress reported.
2. What is the exact Definition of Done? Getting something done usually involves the stakeholders, and that happens, most of the time, by the end of the iteration (review meeting), which won’t help in keeping the burn-down chart updated.

The need for absolute estimates

It was obvious to me that the real benefits gained from relative estimates are not fully understood by some. Using relative estimates is crucial, but it’s definitely not the only exercise to be done during a project. Absolute estimates also play an important role that cannot be underestimated. I’m not a fundamentalist when it comes to Agile methods that you can or cannot use. But whatever they are, just make sure that you understand the reasons behind your choice for using them and the real benefits gained. This is my simple and humble recommendation.

Article available at Scrum Alliance