The product backlog is an ordered list of all project requirements. Started at the beginning of a project, this single list of requirements is arguably the most important artifact in any agile project.
Requirements in agile projects generally follow the user story format. The product owner is responsible for creating, maintaining, and for ordering the list. This includes adding new stories, changing stories, and deleting stories that are no longer necessary. It is completely normal for the product backlog to constantly change, both in terms of size and the order of the requirements.
It is vital that the product owner keeps the product backlog in top shape. Regardless of how fast your agile development team achieves excellence or how brilliant their continuous integration solution works – it all becomes irrelevant if you are building the wrong product.
At the very minimum, a product backlog has to include the following information:
- Description of the requirements / user stories
- Relative order or priority of the user stories
- Estimate of effort
Here is an example of a product backlog:
|121||As an Administrator, I want to link accounts to profiles, so that customers can access new accounts.||Feature||In progress||5|
|113||As a Customer, I want to view my account balances, so that I know how much money is currently in each account.||Feature||In progress||3|
|403||As a Customer, I want to transfer money between my active accounts, so that I can adjust each account’s balance.||Feature||Not started||1|
|97||As a Site Visitor, I want to contact the bank, so that I can ask questions and raise issues.||Feature||Not started||2|
|68||As a Site Visitor, I want to find locations, so that I can use bank services.||Feature||Not started||8|
While the product owner controls the content of the backlog, he or she does not have authority over the estimates attached to each user story. Those are in the sole remit of the development team.
For example, the product backlog is a key input to the sprint planning meeting. At the meeting’s start, the development team takes the top requirement in the backlog and confirms whether they can commit to complete it during the sprint. Another example is when the team runs out of work during the sprint. They then turn to the product backlog to choose which feature to work on next.
For more information, see our previous blog post on the different kinds of Agile Project Management Artifacts.