20 May 2012

Visualising your Product Backlog

Have you heard that a product backlog is a prioritised list of features/epics/stories (requirements), bugs and technical debt/work? I suppose that's OK, but if you want to make it really effective then it should be visual. Let's take a look at how to do that.

Background

If you haven't got a product backlog then you're not doing Scrum, it's a simple as that. If you're reading this then you probably are and therefore have, or at least you know that it's one of the artifacts you need. If you haven't then I suggest you read the Scrum Guide then come back.

When my team started using Scrum our product backlog was kept on a spreadsheet. It was sufficient at first but we soon realised that it wasn't going to be good enough. In particular our problems were:
  1. We needed to cut, paste and insert rows when splitting/merging stories
  2. The priority was descending, even if two or more stories were equally prioritised it didn't look like it
  3. Most of the time it was invisible to most of the team/stakeholders
We decided to leave the spreadsheet and instead tried using software built for the job. Again, this was OK for a while. It was easier to move stories around, and the UI enabled us to better see the priority. However, the third problem above still existed. The phrase 'Out of sight, out of mind' was very appropriate!

So, what next? Google is one of my best friends, often helping out with fantastic suggestions when I'm stumped. That's when I first came across this post on Story Maps. It seemed like a great idea so I started experimenting with it. For us it turned out to be a great way of splitting features/epics into suitably sized stories but we soon ran out of space when we were adding all the stories from our product backlog. If you're going to do this then you'll need a suitably sized wall and we simply didn't have one! We do still use story maps and find them very useful, although we've adapted how. You can see my post about it here.

It was in a series of discussions I had with the ScrumMaster and Product Owner on my team, followed by some refining in practice, we established a way to visualise the product backlog that worked for us. Here's a step-by-step guide to show how it works:

Visual Backlog

Step 1 - Stories on sticky notes

All of the stories in the product backlog are written on sticky notes. We use two colours - yellow for stories that are 'sprint ready', green for those that aren't.

A 'sprint ready' story:
  1. Follows the INVEST guidelines
  2. Has acceptance tests/criteria
  3. Has been sized
If we have related stories (e.g. they have resulted from splitting a larger story/epic) then we note the theme too, acceptance criteria are written on the back. Here's what they look like:
Click on image to enlarge

Step 2 - Stick them on the wall

We found a wall in our office next to where our Scrum team work that a people outside of the team walk past. We stick the stories onto it placing those with the highest priority on the right-hand-side:
Click on image to enlarge

Step 3 - Add some information

Any passer-by looking at the wall as it stands will just see a bunch of stories, we needed to make it clearer. Here's what we came up with:
Click on image to enlarge
In the top-left corner is a key to show the difference between green and yellow stick notes, there's an arrow at the top to indicate priority, you can see which stories are candidates for the next sprint and you can also see where the cut-off point is for stories to be included in the next release.

Step 4 - Using it in practice

Only the Product Owner is allowed to add, remove or move stories on the wall. This is important as it is they who has a view of every stakeholders needs and wants. If a stakeholder wants a new story added or thinks the priority should be changed it us up to the Product Owner to manage that and the stakeholder should speak with them about it.

If you've been working on a story and as a result it has been split then you should work with the Product Owner to establish where the new stories should be placed.

Here's a picture of our Product Backlog, it's from a previous iteration where we used a pink sticky note to indicate the Release Candidate marker and didn't have anything to show which stories are sprint candidates but it was certainly effective:
Click on image to enlarge

Step 5 - Further tips

Here are some other things you might find useful:
  1. Use another colour sticky note for bugs and add them to the wall
  2. The green stories that are nearest the right-hand-side need splitting/merging/etc. to be sprint ready. We stick a small photo on it of the Business Analyst who is currently owning that piece of work
  3. If you're trying to get a story sprint ready and it is blocked (e.g. waiting for a response from a third party) then add a note to the green story saying so. We write the info on an orange sticky note and attached it to the bottom
  4. If a stakeholder wants to know when the release candidate will be ready, you can forecast by first getting those stories in it sprint ready, totalling their size and (using the team's sprint velocity) calculating the number of sprints it will take. Careful with setting expectations though, I will write a blogpost about this soon...
  5. Keep your handwriting neat and use a decent pen!

Complex backlogs

I was speaking with someone recently about how we've visualised our product backlog and he asked me how I'd deal with one that was more complex.

If you have multiple projects/workstreams you could put coloured stickers on the top corner of each story with each colour representing a different project. This will probably work best if you have one Scrum team and Product Owner.

If you have multiple Scrum teams then you just need to have separate backlogs. However, people outside of the team might not care about how many Scrum teams you have so you can use swimlanes rather than different walls so all of the information is in one place.

Conclusion

Having our product backlog on the wall gives us many advantages, in particular:
  1. It is easy to reprioritise stories, just move them around!
  2. Everyone in the office can see what's coming up for development
  3. Some people often underestimated the amount of work required for the next release candidate, not anymore!
If you visualise your product backlog using this method or another I'd love to hear about it!

1 comment:

  1. Hi Russ. This process looks quite similar to one we adopted, but people got fed-up with picking post-its off the floor or forgetting to move them.

    After a very successful trial, we've decided to use a tool which plugs into TFS - http://www.telerik.com/agile-project-management-tools.

    We're just waiting for the new Scrum room to have a 60" touch screen fitted before it's used in anger. :D

    ReplyDelete