Refining your backlogs

My previous update on Backlogs provided an introduction to the term. This post provides a little more detail on how to work with Backlogs.

About agile in Cornwall Council

We are starting to adopt more agile ways of working. My role involves helping people develop their skills and apply agile techniques to improve the services we provide to the public. This series of posts is adapted from the articles I write for our internal teams. They cover some common agile terms and what it all really means.

In my first note^[1] I described two types of backlogs, product backlogs and work backlogs, which have slightly different roles.

Refining your Product Backlog

The product backlog is made up of the things that describe what your product or service will need to do for your users e.g. “let an officer capture the results of an inspection while they are away from the office”. Your first product backlog might be quite scrappy but the team can refine the backlog bit by bit each sprint^[2]. The sorts of refinements you might see are:

• Moving the items around so the most important and urgent items go at the top of the list and less urgent and important ones move towards the bottom. Getting a good order that works for the team and other stakeholders is one of the key jobs of the product owner.
• Rewording items to make them clearer with a user focused format (see our earlier post on user stories^[3] for a common format but there are others you can use). People with business analysis experience are usually pretty good at helping the team do this.
• Merging small items or breaking down large ones so that they are easier to manage (some of our teams are already using labels like story, feature, epic and theme to indicate the scale of the their items)
• Adding additional information such as business impact, key constraints, estimates and acceptance criteria.

Refining your Work Backlog

The work backlog is made up of all of key tasks and activities that the team needs to do. Many of these will link directly to something on the product backlog e.g. “amend some code to implement a new feature”. There will usually be some housekeeping tasks such as setting up the team workspace and improvement activities coming out from regular team reviews. In the first sprints quite a lot of the work could be this sort of housekeeping but it is a good idea to have a mix each sprint. Generally, teams find that they don’t need much structure for the work backlog but typical things the team will do when planning a sprint is to:

• Review how much work they can realistically get done
• Decide on what work is the highest priority
• Juggle things around to get a sensible work list for the next sprint
• Add other helpful information such as status of the work, sub-tasks or checklists, any external help needed and estimates^[4].

Footnotes