Relative estimation is the process of estimating task completion, not by units of time, but rather by how items are similar to each other in terms of complexity.
The Agile Alliance gives this definition:
Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty
The Ordering Coffee Example
Here is an experience that you may have had in the past!
You order a coffee and the barista says, "No problem! What size?"
Because you have never been in this coffee shop before, you don't know what sizes they have. How large is a large? Is it a two liter cup of coffee? If it were, you wouldn't sleep for about a month! 😱
Typically you can see the cup sizes on top of the coffee machine and make your choice from there.
If you take a moment to examine what the voice inside your head is saying, you might notice:
You are not trying to consider whether the medium cup is 40cl or 55cl.
You are not asking, "How much coffee is in the medium cup?"
You may well be thinking, "Small is too small, but large is also a bit big, so I'll go medium."
Another way to think about this is that you are doing a "relative sizing" estimate. You are thinking back to previous cups of coffee you have had and wondering which of the three cups is the same size as you normally prefer.
Baristas know the benefits of relative sizing!
The House Painting Example
Imagine that you are painting a house. The house has three large rooms, four medium rooms, and two small rooms. You know that painting a medium room takes one week.
You could make the following assumptions:
A big room would take two weeks to paint.
A small room takes a half week to paint.
Using these assumptions:
Painting three big rooms would take six weeks.
Painting four medium rooms would take four weeks.
Painting the two small rooms would take one week.
Using relative estimates, you could determine that it would take a total of 11 weeks to paint the house.
Now instead of a week, imagine that painting a medium room involves one unit of time. Then painting the house takes 11 units of time.
Sometimes an experienced painter could paint a medium room in three days for example, but a new painter might take six days. So you have avoided saying 11 weeks - you just know that painting the house is "11 times more big" than painting a medium room - and that's the spirit of relative estimation.
You may be thinking to yourself that these relative sizing examples make sense! But what has this got to do with product management?
When you are estimating how long it will take to build the features of a product when your method of estimation is to relate to previous work you have done, then the estimates are more accurate than when you just deconstruct features into sub-tasks and estimate them all.
Studies show that the relative sizing approach provides better estimates than an absolute sizing approach.
In the example below, you are tasked with reading a book. How long will it take? First, estimate the complexity of the task and then compare it to a previous book you have read. This splits the estimation into two phases: how big it is and how long it will take you to complete.
The Book Example
Imagine asking your friends how big a book is. You could expect answers like:
"About 10 hours"
You might notice that there are several ways to answer the question.
The physical dimensions (height, width, length) of the book.
The number of pages in the book.
The amount of time it would take to read it.
Splitting Size and Duration
The fact that there are a number of answers to the question of how big a book is tells us something - this is an ambiguous question. People who ask "how big" something is may have different answers in mind.
When stakeholders take part in an estimation session, they want to know how long it will take to build the feature.
If you want the benefits from relative estimation, then you should answer that question in two steps:
Estimate how big the task is.
Estimate how long it will take to complete.
Benefits of Relative Estimation
Why not just estimate in hours how long all tasks and features will take? Here are the reasons why relative estimation is favorable in Agile software development:
The human brain works well with relative comparison - we have an inbuilt sense of something being relatively bigger or smaller than something else.
This explains why team members are much more comfortable with relative estimation. Team members often hesitate to provide estimates of how long tasks will take to complete. They are aware that they typically do not have all necessary information at the time of estimating and so they do not feel confident to say how long a task will take. They feel much more comfortable to give their opinion on whether a task is bigger or smaller than another task by comparison.
Stakeholders or project managers sometimes mistakenly take time estimates as commitments and breed an expectation that features will be completed in this time, rather than just using them as an input to decision-making. It is impossible to take relative estimates as time commitments because relative estimates are not measured in time taken.
When asked how long a task will take to complete, team members sometimes "inflate" time estimates so that there is some built-in slack when more complex details become known. You can avoid this problem with relative estimation.
Relative estimation is proven to be effective and provides more accurate estimates. In this study, an experienced project manager estimates a complex project. By comparing his project to similar projects, he provides a more accurate estimate than four other project managers using more analytical approaches.
Relative estimation is the process of estimating task completion by comparing them to previously completed tasks.
The human brain is naturally hard-wired to work better with relative comparison.
Relative estimation provides better estimates.
Relative estimation works by estimating size first so you can relate this size to a task you have completed previously. Then you estimate how long the task will take to complete by making a relative comparison to the time taken to complete this other task.
Mike Cohn provides several references in his book Agile Estimation and Planning, to support the benefits of relative estimation:
Miranda (2001) writes this paper on Improving Subjective Estimates Using Paired Comparisons, which suggests that pairing a feature to the the most similarly complex item in a given list provided more accurate estimates than ad hoc estimation.
A study was done using a sample of five projects managed to prove that relative estimation is the most effective.