Why do You Think a Team Might Choose to Use Relative Estimation?
I like to start with asking why do you think a team might choose to use relative estimation for Product Backlog Items? In your experience, have you found it useful? Has it been confusing? What method did you use? T-shirt sizes? Story Points?
Perhaps you’ve never used relative estimation at all. If not, what have you used? How has that worked for your team(s)?
Estimation Using Hours as a Team
There is a great analogy that I first heard from Henrik Kniberg, the Agile expert once of Spotify, about estimating a task as a team using time.
Kniberg starts by taking Usain Bolt and a turtle, putting them on the same team, and giving them a task of running to a tree in a field. Asking this team to come to an agreement of how long this task will take is quite amusing. Usain Bolt says it’ll take ten seconds. The turtle, however, says it’ll take three hours.
Both Bolt and the turtle might be correct in their estimations, but as a team their understanding of the task at hand can deteriorate. When you add more team members, the complexity towards achieving that understanding increases.
The key component to realising the value of a team estimate is to have team understanding. How can a team fairly share responsibility for completing work if only one or two members of that team understand the work’s estimation?
This is where relative estimation comes in.
Let’s create a little project: we as a team need to replace a Person’s kidney. There are three Product Backlog Items that need estimating:
- Hiring the surgery room.
- Hiring a nurse.
- Replacing the kidney.
We start by establishing a baseline; a Backlog Item in which we can assign a size (as arbitrary as that might be) so that we can relatively work off it when sizing other Backlog Items.
Pick a Product Backlog Item and assign it a size of your choice – for simplicity, let’s go with either Small, Medium, or Large.
Next we look at another Product Backlog Item and compare it to the first. Is it smaller or larger?
Pick another Product Backlog Item and assign it a size of your choice, but do this by comparing it to the baseline.
Perhaps hiring the nurse seems relatively small when comparing it to replacing the kidney.
Perhaps the team is quite good at replacing kidneys, and the tricky bit is hiring the nurse, and perhaps a much bigger task.
You may need to assign the size Smaller, Extra Large, or something along those lines.
Finally, we pick the last item and do the same to assign it a size; comparing it to a couple other items (in this case the only other items on the backlog!)
Finish estimating the Product Backlog by assigning a size to the remaining Backlog Item using the same techniques applied above.
Here is what our team decided (this may or may not be exactly the same as yours, but that’s fine!):
- Hiring the surgery room. – Extra Small
- Hiring a nurse. – Small
- Replacing the kidney. – Extra Large
What we have established here is, even without knowing in great detail the work involved, the amount of time it might take, etc., we can apply an estimation of size using relative estimation. As a team, we now understand what extra small, small, medium, large, and extra large stories start to mean.
Half Pint Full Pint
Another way of understanding relative sizing is taking a half pint glass and a full pint glass. Imagine I was to show Person A a half pint glass, and asked them to provide their best estimate as to how many pennies can fit in the glass. Now imagine I show Person B a full pint glass, and ask them to estimate how many pennies fit in that glass. It’s unlikely that Person A’s estimate would be even roughly half that of Person B’s (as it should be, because, it’s half a pint).
Let’s now ask Person A to compare the two glasses and ask them to determine the size of each. Then we can do the same with Person B. They will likely both establish that the size of the full pint glass is roughly twice as big as the half pint glass.
Again, what we have established here is some understanding of the size of each glass (or task). When the glasses are eventually filled with pennies, however many that may be, Person A and B will have an idea of what’s involved in filling other glasses based on their apparent size.
The problem a lot of teams encounter with labeling a task a size such as small, medium, or large, is that it becomes difficult to track and monitor. This is particularly important in Scrum, for example, when a team wants to keep track of its velocity, or when a Product Owner must be able to sum remaining work towards a particular goal or mission.
Here is where we introduce story points. This is the conversion of the sizes applied above into a numerical value that can easily be understood. For example, a team might assign a small task with 5 story points, a medium with 10, and a large with 15.
It’s important that these points are not sub-consciously (or consciously) converted back into an hourly estimate.
They are simply a numerical way of looking at sizes. The most common system for assigning story points is with the Fibonacci Series using a method called Planning Poker. The reasons for using this approach and method are out of scope for this article, but, because of their popularity, they’re worth mentioning.
Team estimation is all about team understanding. Relative estimation helps improve this understanding by providing a solution to the problems frequently encountered with time-based estimation.
If you have any suggestions (grammar, punctuation, spelling, content, etc.) please post a comment below! This article is a living document!