Agile Concepts: The Product Backlog
In simplest terms the product backlog is a to-do list for the team – a list of all of a product’s features in priority order.
In Scrum the product backlog is usually first generated by a workshop of stakeholders (including the Product Owner) – perhaps guided by a Product Vision – where all of the important features that can be thought of are noted down.
This list then feeds into the first sprint backlog. After that, as the Scrum team gains a fuller understanding of the product and the customer’s needs, the product backlog will grow and develop through successive iterations.
The different kinds of items on a product backlog
The most common type of item on a product backlog will be user stories – short descriptions of a piece of functionality described from the user’s perspective e.g. ‘As a customer I want to be able to sign up to an email newsletter so that I receive information about special offers’
The product backlog might also contain bugs, EPICs (stories that need to be broken up into smaller user stories), technical ‘spike’ stories or knowledge discovery stories.
The Product Owner and the Product Backlog
The Product Owner owns priority and value in the product backlog. They should be working with their stakeholders, market information and product knowledge to create a roadmap that is reflected in the backlog.
Although the Product Owner has a key role in managing the backlog they shouldn’t be a gatekeeper of it, the backlog should be available to everyone to view at any time and anyone can write a story to be added to it.
Refining the product backlog
Sometimes a Scrum team will incorporate a backlog refinement meeting into its sprint routine. This is usually a time-boxed meeting which takes place mid-sprint. The objective is to get enough of the product backlog ready to comfortably populate the next sprint backlog.
Backlog refinement is used to refine the items near the top of the backlog: to break them up into user stories that can be tackled in a single sprint, to agree on acceptance criteria for those stories and, often, to estimate them (normally by attributing story points).
As they work through each item in priority order the team can reach consensus over:
- which items are of an appropriate size for inclusion in a sprint and which need to be broken down into smaller stories;
- what criteria need to be met in order for the story to be considered ‘done’ (the acceptance criteria); and
- the relative size of the story (normally in story points) – useful for sprint planning and for measuring the velocity of the team.
There are several techniques for estimating the size of items. In Scrum the most common approach is the use of planning poker to attribute story points to each user story.