Relative Sizing

Introduction

In order to plan effectively we need to have the size of work estimated by the Dev Team.

Planning comes at several levels:

  • Planning Sprints
  • Planning a Quarter (a Quarter is sometimes called a Release - but has no relation to deployment of any product, so this is sometimes called Release Planning)
  • Planning the Product Roadmap

Planning the roadmap is usually an exercise for Product. As the timescale involved is considered to be speculative, the Dev Team are rarely involved in estimating work items more than 3 months into the future. So I will not cover roadmap planning here.

Planning Sprints is the typical use-case when talking about story refinement. As a SCRUM Team we should aim to have around 2 sprints' worth of work refined and sized ready to go into sprint. These should be refined estimates where the team has had the chance to talk about each work item and voted on the size of the work item, discussing where they disagree and coming to a team consensus on size. This is usual refinement and story estimation, so I won't go into that here.

Release Planning / Epic Breakdown / Feature Breakdown. Breaking features / Epics or a larger bunch of Epics for an entire release is where relative sizing really becomes a powerful tool.

Relative Sizing - Advantages and Disadvantages

Advantages of Relative Sizing

Relative Sizing has several advantages over traditional sizing during refinement:

  • The team are able to retain the high level overview of what the goal is without being sucked into too much detail
  • Many more work items can be estimated in one session than would be possible in standard refinement
  • The average amount of time taken to estimate each work item is shorter
  • It can be used to break down up to three months worth of work, providing more information to plan and prioritise

Disadvantages of Relative Sizing

There are drawbacks to relative sizing:

  • The estimates a rough. During relative sizing we don't go into full-blown discussions around each work item, but just try to sketch it out so we roughly know what's involved and what the scope is
  • You will still need refinement sessions to get a better estimate to help with sprint planning and make sure all the detail of each story are understood

How Relative Sizing Works

Basics of Relative Sizing

The main principle of relative sizing is that you get a bunch of work items. Each has a description and acceptance criteria and has been discussed at a high level.

You then group the work items into work items of similar size. Place smaller items in a different group and larger in another different group. I typically use columns and place work items of similar size in the same column, smaller items in columns to their left and larger items in columns to their right.

If a work item is larger than one column, but smaller than the next column, then make space for it between these two columns and make a new column.

Continue this until all work items have been placed into columns. Initially we're not too worried about how many columns we have.

All work items have now been relatively sized. We start to get the value from this process when we put story points against these work items.

Putting Rough Story Points Against Relatively Sized Work Items

Starting at the right-most column (largest work items), ask the dev team if they would accept work items in this column into sprint. (i.e. What we're asking here is if the work items in this column fit into the team norms for max sprint story size).

For argument's sake, lets say that a team would allow an 8 point story into sprint, but would not allow a 13 point story into sprint without splitting.

Once you identify the right-most column that the team would allow into sprint ask if these stories are 8 point stories or smaller. Let the team discuss amongst themselves what the size of that group of stories is. Put a planning poker card on that column with what they decide. Work items in columns to the right of this column will need to be broken down, but rather than do that now, move on to the left-most (smallest) group of stories. Ask the team for the size of these work items. Once they select a size, then put a planning poker card on this group.

Depending on how many columns are in-between these two you can now put out the other planning poker cards between these two limits. If there are fewer columns than cards, let the team put planning poker cards over the columns, discarding any card that didn't apply. If there are more columns than cards (which is the most common scenario), let the team decide which columns should merge to fit under the planning poker cards.

What About Work Items Where We Have No Idea of Size?

For work items where the team simply have no idea what their size may be, put them in a separate pile/column. We'll need to deal with these differently.

How to Deal with Bigger Sized Work Items

So this leaves you with larger work items. What you do now is determined by what you need to achieve. There are two options I have encountered and used:

Option 1 - Size Bigger Work Items

You could allow the team to place planning poker cards (13, 20, 30 etc..) on these larger columns and have a separate session to split these work items (this may be enough for release planning).

Option 2 - Break Down Bigger Work Items

Alternatively, you could take each of the larger work items and discuss how to split them into two or more smaller work items.. placing the new, smaller work items in the sized columns as they are broken down.

Conclusion

At the end of the session you should end up with each work item either sized, or identified as needing further investigation. Spikes/Timeboxes/Investigations should be raised for each of the work items that couldn't be sized where applicable.

The rough sized stories are now ready to be used for planning the release with the understanding that all sizing at this stage is rough and is likely to change. This sizing, although rough, should enable the PO to prioritise work based on its value and time it will take to develop.