Backlog Management

In a nutshell, a backlog is a prioritised list of user stories. The priorities are based on the value the stories will deliver, the dependencies on other parts of what we'll deliver, the amount of effort required to develop and any time critical events.

Two Backlogs

There are two types of backlog. First, there’s the product backlog. Second, there’s the sprint backlog.

The product backlog is the big bucket, or container, into which all of the requirements, or user stories are kept. The job of the Product Owner, ably assisted by the Scrummaster, is to ensure that the backlog is prioritised with the highest value stories being placed at the top of the backlog ready for the next sprint planning session.

If you’re new to Agile then you could think of the backlog as your project initiation document. The difference with Agile is that your requirements are flexible and can change regularly without the overhead of traditional change controls.

Product Backlog

This is the main repository into which you’ll put the user stories for the development. When adding stories here, they don’t have to be fully detailed with supporting documentation. Instead, you can put placeholder stories here for larger pieces of work. We describe these as epics.

We use epics to describe large requirements. For example, "I want users to be able to book a meeting room”. This doesn’t say much, it doesn’t describe any benefits, any value, nothing is backed up by user research and we know nothing of the backend functionality required to manage this. What we do have is a placeholder for a potentially valuable story so that it’s not forgotten and can be investigated and broken down into smaller stories at a later date.

It’s the Product Owner’s job, with support from the Scrummaster, to keep the backlog up to date. Those user stories that will deliver the highest value should be placed at the top of the backlog. As a rule, the top 10-20 stories should be properly written ready for the next sprint planning session. During any sprint you should be working on the highest priority stories preparing them for the next sprint planning session.

Sprint Backlog

Each time we plan a sprint we start a new sprint backlog. During the planning session we take the highest priority stories from the product backlog and place them into the current sprint backlog. At the end of that planning session the backlog is effectively closed, no more stories should be added during the sprint.

Next stage: Sprint Planning