An introduction to backlogs

In this post, we’re taking a closer look at another agile term: Backlog. The dictionary definition is:

an accumulation of tasks unperformed or materials not processed

In agile working, backlogs are a list of things that a team still has to do. If you are struggling to get started, brainstorming a list of what a team needs to do is a good first step.

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.

Getting your work organised

For most teams, organising your backlog^[1] can help. Start by sorting your list into a product backlog and a work backlog.

• What is a Product Backlog?

  The product backlog is made up of the things that describe what the product or service you are building needs to do for your users. Your first product backlog might be quite scrappy (see the Bumblebee board^[2] for an example of how scrappy this can be!) but the team can refine the backlog gradually through each sprint.

• What is a Work Backlog?

  The work backlog is made up of all of the key tasks and activities that the team needs to do. Many of these will link to something directly on the product backlog e.g. amending 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 sprint, quite a lot of the work could be this sort of housekeeping, but it is a good idea to have a mix of work in each sprint.

You can keep track of your backlogs in a variety of ways. Some use sticky notes and white boards and there are others who use software tools. Many of the IS teams at Cornwall use Azure Boards^[3]. Some teams keep their product and work backlogs separate, while others use a single list with labels.

Backlogs can be a great source of management information. Some of our teams are already generating this in real-time as their work progresses.

Most teams can get what they need from product and work backlogs, but you may come across teams using other backlogs covering things such as service requests, architecture, enablers and risks.

Footnotes