The Ideal Backlog

The Ideal Backlog

One aspect of agile working that people are often unclear about is what makes a good backlog.

Two of the artefacts in Scrum are backlogs – the product backlog and the sprint backlog.  The Scrum guide gives us some information about how we go about creating a sprint backlog but doesn’t say much about the product backlog, other than it’s the list or queue of all the work yet to be done and that it needs constant refinement.

The work to produce and manage the items in a product backlog is now being heavily influenced by approaches and techniques that look to identify customer value, approaches like Lean UX, and techniques like story mapping and impact mapping.

However, while these approaches and techniques are useful, none provide any guide about what an ideal, or at least good backlog should look like.

I thought that this would be an interesting topic for a talk and discussion, so put together some slides and delivered it to the Agile Sheffield Meetup group on 26th October 2017.

While putting together the talk, I started to create a list of the things that emerged from examining aspects of backlogs.  Here’s the initial list:

  1. Not make you feel bad.  There’s a few definitions of the word backlog and many imply that it refers to an accumulation of unfinished work:  “we needed to work the weekend to clear the backlog…”.  This definition makes it feel like we’ve fallen behind, it feels negative, a bit depressing when we refer to the backlog in this way.  However, when considered from an agile standpoint it should be viewed as a set of work thats going to make a positive difference to its users – it’s going to provide something of real value.
  2. Does not always contain work to build individual product features.   This item came about as I was thinking about Release backlogs.  Release backlogs typically comprise a subset of features from the product backlog that are planned to be delivered together.  However, there’s also a set of work to pull together potentially releasable product increments into a releasable product and this work is sometimes grouped into a Release Backlog.  This work does not contribute to product features – it’s just a set of tasks, its work yet to be done.  So our backlogs can comprise user stories, tasks or anything else that contributes to the delivery of the product.  However, upon reflection of this item and its similarity to item 8 which has stronger reasoning, this item is being removed from the list.
  3. Prioritised – Customer value & Size.  A key responsibility of Product Owners is to continuously refine the product backlog, which includes continual prioritisation with high value, granular detailed items at the top and low value, coarse-grained items at the bottom.  A tip is to size first as this helps to identify and continually validate the teams capacity and velocity (the rate at which they can get work items done).  Once you know the teams velocity, product owners can use this to referee stakeholders needs.  E.g:  “The teams velocity is 9 stories per week – that’s the maximum number of stories the team can work on.  Of all of the stories you want the team to work, which 9 do you want them to work on this week?” 
  4. Always changing.  Backlog refinement is an ongoing activity and so the backlog is never static.  It should be treated as such and not just left once created.  
  5. Visible.  The continual change to the product backlog means that communication of the changes need to be frequent and effective.  The best way to do this is to not have to explicitly communicate them at all, but instead make the product backlog visible to all.
  6. Help us with planning.  The value-based prioritisation approach we take to refinement means that the things at the top we will work on now or next, the things in the middle will be worked on soon after that and the things at the bottom will be worked on some time in the future (if it all).  So that implies that we could use our product backlog for high-level planning, to give us a strategic roadmap of when things are likely to get done.  Not exact dates, but an idea about the order in which things will be delivered and rough timescales.
  7. Be organised so that we can visualise the entire product & current status.  Product backlogs represent the scope of all of the things that will be built to deliver the product.  So we should try to organise them in some way so that we can understand how they relate to one another.  This will provide insight into dependancies, help us identify gaps and helps us with refinement work, especially prioritisation.  Story mapping is an excellent techniques that helps us achieve all of these things.
  8. Hold appropriate types of placeholders for work (for the product at that point in time).  We’re used to our backlogs containing user stories, but they could and probably should contain whatever is necessary and appropriate for the team to get work done at that particular point in time.  E.g. when we first start out with an idea or are given a mandate to deliver something, the work that we do is often unstructured.  We don’t know what we’re going to be building, there’s a lot to find out, a lot of user research to do.  We hypothesise a lot, come up with lots of ideas – throw out the ones that don’t deliver value and keep the ones that do.  We’re probably not building anything concrete just yet, but are probably developing some prototypes to help us better understand our users needs.  So at this point in the lifecycle of our product or service it doesn’t make any sense to spend lots of effort on writing and refining user stories – much better to track and mange work on more lightweight, responsive artefacts like hypothesise.
  9. Contain work appropriate for the people doing the work.  The concept of a product backlog is based upon the premise that a product delivers the most value when the same team develops and maintains the product from its inception, through build, into support and continual improvement until it’s no longer needed.  In many cases this premise holds true and as team members come and go, the one thing that remains is the product.  However, the increase to customer value slows as soon as the product is released and starts to plateau once the most important and valuable features are delivered, leaving the team with capacity to do other things.  So teams may shrink – team members go off to join other teams where their skills and experience can be better utilised, or the team might start working on a new product.  So the backlog turns from a product backlog into a team backlog.  Team backlogs are also pretty common amongst operational teams where they have to deal with lots of different types of work while using and/or maintaining an existing product.

After considering these further I realised that items 2 & 8 were really the same thing, just arrived at from different perspectives, so I’ve removed item 2 from the list.  I also renamed some of the points.

  1. Represent items of value and worth to users
  2. Prioritised by user value and size
  3. Dynamic
  4. Visible
  5. Provide a strategic view of the sequence of delivery
  6. Visually show scope, context and progress
  7. Contain types of work appropriate for that point in time
  8. Contain types of work that the team can deliver

The list does seem to provide a good guide for what a good product backlog looks like, with some items more important than others.  However, it’s not definitive for all types of backlog at all times during a products lifecycle so it’s worth challenging especially early on in a products lifecycle when there are so many unknowns – perhaps this is where value is around increasing team knowledge and decreasing risks.  Further work ahead me thinks.

Click here to view the slides.


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: