The Product Backlog is the ordered list of everything needed to improve a product: new features, improvements, requirements, technical work and bug fixes. It is one of the three artefacts of Scrum, alongside the Sprint Backlog and the Increment. The Product Owner is accountable for it.
What is a Product Backlog?
The Scrum Guide calls the Product Backlog an emergent, ordered list of what is needed to improve the product. Two words matter here:
- Ordered: what delivers the most value or is most needed is at the top. That tells the team what to do first.
- Emergent: the list is never finished. Items are added, items are dropped and the order changes, every time something new is learned. That is the big difference from a fixed set of requirements in a waterfall project.
Above the list sits the Product Goal: the future state of the product the team is working towards. Every item on the Product Backlog contributes to it. What doesn’t contribute doesn’t belong on it.
What is in a Product Backlog?
The items are called Product Backlog Items. They are often written as a user story, but that is not required: a bug, a technical task or an experiment can also be an item.
The items at the top are small, clear and estimated, so the Developers can pick them up in the next Sprint. The lower on the list, the larger and vaguer the items, as shown in the image at the top of this article. That is not sloppiness but a deliberate choice: it is wasteful to spend time detailing something that may never be built.
Refining the Product Backlog
Working out items in more detail is called refinement. The Product Owner and the Developers do this together: they split large items, add detail and estimate size. The Developers who will do the work are responsible for the estimates.
According to Roman Pichler, a good Product Backlog is DEEP: detailed appropriately (detailed at the top, rough at the bottom), estimated, emergent and prioritised.
Who is accountable?
The Product Owner is accountable for the Product Backlog: for what is on it, for the order, and for making the Product Goal and the items clear. They gather wishes from customers and other stakeholders and weigh them against each other. The Product Owner can delegate some of the work, but remains accountable.
The Scrum Master helps: by offering techniques for a clear Product Goal and a well-managed backlog, and by making sure the list doesn’t become a messy wish list, but a means to deliver value.
Product Backlog and Sprint Backlog
Scrum has two backlogs. The overview below puts them side by side.
This is one of the tools you learn to apply in the Green Belt training.
In Sprint Planning the Developers, together with the Product Owner, choose which Product Backlog items to take on in the coming Sprint, and they formulate a Sprint Goal. Those items, the Sprint Goal and the plan to deliver them together form the Sprint Backlog.
A common misconception is that the Sprint Backlog is fixed during the Sprint. It isn’t: the Developers update the plan as they learn more. What is fixed is the Sprint Goal. If more or less work turns out to be needed, the Developers discuss it with the Product Owner, without letting go of the Sprint Goal.
At the end of the Sprint, in the Sprint Review, the team and stakeholders look at the result. What is learned there goes back to the Product Backlog: new items, a different order, or items that are dropped. That keeps the list alive.
Where it often goes wrong
- An endless list. A backlog with hundreds of items no longer gives direction. Dare to throw items away: what matters will come back.
- Everything equally important. A backlog is an order, not a pile. There is always one item at the top.
- Too much detailed at once. Only work out the items at the top in detail.
- No Product Goal. Without a goal there is no basis for choosing or dropping items.