Relative Estimation Playbook

Overview

Being able to estimate our work is an important capability. Even in agile organisations that are comfortable with ambiguity, we still need to prioritise and have some idea of when something will be done.

This playbook provides an introduction to how you can use relative estimation to encourage rich conversations that are often more valuable than the estimate itself.

There are 5 steps in completing this Playbook

Introduction
Preparation
Baselining recent work
Facilitation techniques
Forecasting and making commitments

Participants

Team
Product Owner
Scrum Master
Invited Stakeholders

Difficulty

3 - Moderate

Duration

Relative

Materials

Team's backlog with refined and understood backlog items

Introduction

Humans are terrible at estimating using absolute numbers!

Whether you're estimating how long something will take, how much something weighs or how wide something is, it's hard if you have to use days, grams or millimetres.

Relative estimation is easy though, I might not be able to estimate how many grams a watermelon weighs, but I can easily assess whether it's lighter or heavier than a strawberry.

Estimating hours or days is hard without a crystal ball. Estimating tasks relative to each other is much easier, (and more accurate,) if all we need to do is determine whether a task is easier or harder than another task.

Absolute estimates...

Require up-front analysis

Absolute estimates require us to know all the detail about what will be done in order to be able to say how long it will take. This means it will take a lot longer before we can start the work.

Parkinson's law

Absolute estimates make us susceptible to Parkinson's Law, having estimated how long something will take, the work naturally expands to fill the time we gave it.

Reduced alignment

Absolute estimates are difficult when there are team members who have different skill levels, those with more experience will estimate a task as taking less time than those with less experience.

Relative estimates...

Less analysis needed

We don't need to know every detail when using relative estimation. We can say something is bigger or smaller than something else, even if we don't know everything yet. This means we can get started sooner.

Less 'gold plating'

We didn't say how long it would take when we applied relative estimation, so the likelihood that it will expand is reduced.

More collaboration

Relative estimates allow more collaboration. Regardless of the level of experience of individual team members, a task is still larger or smaller than the task we are comparing it to.

Preparation

Preparing for estimation involves readiness in the work to be done and readiness in the people who will do that work.

Ensure the Team is familiar with the work to be done, prior to your estimation session, the work doesn't need to be fully refined or documented but the Team should arrive with an understanding of the desired outcomes, what the work is and be ready with any questions.

Holding a workshop to teach the concepts combined with baselining your recent work, (see below,) is a great starting point.

PRO TIP!

Ensure you include the right people:

The whole team
Your Product Owner, (if you're doing Scrum)
Invited Subject Matter Experts who can help with any questions the Team might have

Baselining recent work

Relative estimation is largely about comparing one work item with another to decide which is bigger.

When you need to provide an estimate for a new piece of work, you simply compare it to your other work to quickly and easily arrive at a meaningful estimate that doesn't need all the analysis to be completed and allows people of differing levels of experience to collaborate.

However, if you're always comparing new work to other new work, then you won't find it easy to provide forecasts or make commitments, for this reason it is a good idea to review your recently completed work to define your baseline that gives you a way to make your estimates more consistent so it is easier to plan for the future.

Choose the measure for estimation

Decide what scale you will use when estimating, many Teams use t-shirt sizes, (xs, s, m, l, xl,) for big things and story points using the Fibonacci sequence, (1, 2, 3, 5, 8, 13, 21,) for small things.

Steps to complete with the whole Team:

Review a reasonable number of recently completed work items, (more than 10, less than 25)
Agree which is the smallest, that is now an example of an extra small item
Agree which is the largest, that is now an example of an extra large item
Identify a work item that is the closest to the middle, that is now an example of a medium item
Next, place each of the remaining work items into size categories based on their size relative to the first few you placed.

Don't spend too long on each item.

If it's bigger than an extra small, but smaller than a medium, call it small and move on. Don't agonise over whether it might be close enough to medium to call it a medium.

As you build up a few more examples, you might find that an item you baselined as one size should actuall be another, that's fine, just resize it and move on.

Facilitation techniques

Here are just a few of the many different ways you can facilitate a relative estimation session with your Team.

Whichever method you choose, there are a couple of things to keep in mind.

Make sure the work item is 'ready'

Don't try to estimate things that the Team has not had the opportunity to refine, you don't need to have every detail analysed, but you do need to be familiar with the outcome we're trying to deliver and people will need just enough info to have a, "How might we do this?" discussion. See the Backlog Refinement Playbook for more details.

Facilitate for psychological safety

It is incredibly important that people feel safe to say they don't understand something about a work item or that they feel it is more complex or difficult than everyone else thinks. The one person on the Team who thinks there will be more difficulty completing something may be the one person who is seeing a complexity the rest of the Team are missing, if they don't feel they can speak freely, the Team may be missing an element of what they need to do and then underestimate it.

Facilitate for equal voice

Equal voice is equally important, hearing from everyone on the Team equally ensures you can consider all viewpoints when estimating a piece of work. Many facilitation techniques will start by individually capturing people's thoughts and inputs, possibly on Post-it Notes, so all ideas can be collected before starting the discussions. As the facilitator, try to keep track of how much each person is contributing, if there are Team members who are speaking less, gently ask them for their thoughts.

Planning Poker

Planning Poker is a great way to facilitate a relative estimation session with psychological safety and equal voice.

To prepare you'll need to provide some way for people to secretly select their estimate before revealing it to the rest of the Team. If you're in the same room, you can give people cards with a t-shirt size or Fibonacci sequence number on each card, if you're facilitating a remote session, you can use one of many free online tools such as Scrum Poker Online.

Having discussed the work item and agreeing that it is ready enough to estimate, ask the team to individually estimate how complex or difficult they believe it to be relative to the baseline items without letting anyone else on the Team know the size or number.
When everyone has selected their estimate, the whole team reveals what they selected simultaneously, this ensures equal voice and also avoids anyone becoming anchored on someone else's estimate simply becasue they spoke first.
If everyone is aligned, then whatever emerged as the consensus size or number is the estimate, record the result and move on to the next work item.
If there is divergence of opinion, explore the thinking of those who are at either end of the scale:

That's interesting Lakshmi that you thought this is larger than the others think it is, is there some complexity you're seeing that the rest of us may have missed?
That's interesting Hiroki that you thought this is smaller than the others think it is, are you maybe imagining a simpler way we could deliver it that the rest of us may have missed

5. After a discussion about the estimates, repeat the

process until a consensus is reached. In some instances consensus will not be possible and you may need to agree how to deal with that situation. Some Teams agree to take the highest estimate if a consensus can't be reached, while others take the middle estimate so long as the entire range is close.

Paired Comparison

The Paired Comparison technique provides a way to facilitate a rich conversation about each work item.

WIth your baseline in place, you simply start at the highest priority item that hasn't already been estimated. Starting anywhere in the scale that makes sense for that item, (medium in thsi example,) ask the Team:

"Is this item bigger, smaller or roughly the same as our baselined medium item?"
- If it is bigger, then ask, "Is it bigger or roughly the same as our baselined large item?"
- If it is smaller, then ask, "Is it smaller or roughly the same as our baselined small item?"

Continue this process until you reach an estimate people can all agree on.

Ensure you allow the conversation to bring out all views and equal voice, Paired Comparison doesn't have the secret balot element that Planning Poker has so it is easy for people to anchor on what other Team members say. Draw out divergence of opinion, "So it looks like we're agreed this item is a large, does anyone think it might be an extra large?"

No estimates

No discussion about relative estimation techniques would be compelte without at least mentioning the "No estimates" method.

There is significnat debate on how effective this is with wonderfully passionate people on both sides of the discussion.

The simplest way to describe the No estimates method is that instead of estimating work, you simply break work down into roughly the same sized work items.

When every item is roughly the same size, there is no need to estimate them at all. When forecasting or making commitments, you can simply count how many work items a deliverable was broken down into.

Forecasting and making commitments

Relative estimation is all well and good for freeing up your team from the difficulty of providing absolute estimates and allowing you to go faster, but you will still need to provide forecasts and make commitments.

The people who provide the funding for what your team does have every right to know how much it will cost, what they will get in return for that investment and when it will be done, but if your team has not said how long it will take, how do you forcast or make commitments on when it will be completed.

Simply put, we perform an analysis of the past so we can provide a forecast of the future.

Looking at the recently completed work that was assessed with the same estimate and derive the range of durations that work took using a scale that makes sense for your context, (in the following example, we'll use a week.) If there is a large range of durations, you might want to include the percentage of times an item was completed at each end of the range.

Language Matters

How you communicate with the leaders you provide estimates to is immensely important, you are establishing an expectation whether you want to or not.

Based on recent performance, the team generally takes between 4 and 8 weeks to deliver an item of this magnitude, so long as higher priorities don't arise, we'll be done between mid May and mid June.
Based on recent performance, there is a 9% chance it will take 4 weeks, 33% chance it will take 5 weeks, 66% 6 weeks, 91% 7 weeks and 99% chance we'll be done in 8 weeks, how many weeks would you like to buy?

What will I have?

How much will it cost?

When will I have it?

In the example to the right, the Team generally completes a large work item in 4 to 8 weeks.

Their average duration for work of this relative magnitude is 6 weeks.

There is a 9% chance that
the work would be completed in 4 weeks and a 91% chance it will be completed in 7 weeks, (only 1 instance in the last 12 large work items took longer than 7 weeks, so if 9% take longer than 7 weeks, we can be confident that 91% will be done in 7 weeks or less.)

You can also leverage more advanced forcasting tools like the release burnup chart or a cumulative flow diagram, but they are beyond the intent of this playbook which should focus on the practice of relative estimation.

How you communicate your forecasts establishes an expectation.