What is the Product Backlog?
The Product Backlog is a summary of the high-level tasks the delivery team and its stakeholders propose should be delivered as part of the Product. As, in Agile, there is a strong bias towards not defining the Product too early – the Product Backlog generally lacks detail. This ensures that effort is not wasted on defining details that:
- cannot be realistically known at such an early stage.
- are very likely to change before they are actually delivered.
There is no problem with including extensive detail if it is genuinely known (e.g., legal or regulatory requirements). But even in such cases, there is seldom any need for the Backlog to define that detail – usually it is enough to provide a link to a corporate or public source that provides the extra information.
Click here for more on how Backlogs evolve and mature over the product’s lifetime.
Creating the Product Backlog
Collaborating closely, the Product Owner and other subject-matter experts, business stakeholders and Agile team members analyse the Product Vision (especially the USPs and product description) into distinct elements. These may consist of placeholders that merely remind you of something you need to work on, general concepts, features, epics, themes and (if appropriate) stories.
Many of these items will become work items (stories) that are delivered in later releases and iterations. Some will evolve in unexpected ways, becoming quite new stories, while others will eventually be discarded. Don’t be too concerned with the viability of items in the Product Backlog – many strange ideas have proved to be unexpectedly valuable!
These ideas, etc., are then combined into a catalogue called the Product Backlog.
Managing the Product Backlog
The Product Backlog is never complete. Not only will there be a constant stream of new ideas but it will contain many items that will never be implemented but were included in the Backlog because they seemed like good ideas at the time!
As the highest-level Backlog, the Product Backlog is also the simplest. While Release and Iteration backlogs include implementation details, the Product Backlog is simply a list of work items. It does not matter how detailed Product Backlog items are: a few words is quite enough if that is all you have. And even where a great deal of detail is included, the Product Owner and the items’ stakeholder must understand that it is provisional, and likely to change as experience and circumstances change.
Remember, in Agile change is good.
Even if the content of the Product Backlog items cannot be fully defined at this level, there are ‘management’ details that need to be added. In particular, Product Backlog items need to be:
|Classified||Product Backlog items should be classified as one of:|
These details should also be treated as provisional, but they are useful for communicating how the Product Vision is being interpreted and for giving a sense of how it may be delivered.