Product Backlog & Prioritization
What is a product backlog?
A list of all the work yet to be done. A ranked list of briefly described feature requests. Ideally, these should be broken down into user stories.
Why is the product backlog important?
It helps guide roadmap planning. Having a list of features whose rank can be changed allows us to welcome new ideas and changes in direction. It helps teams focus on delivering the highest value first; teams rank and re-rank for value.
Characteristics of the product backlog
Backlogs can be worked on by a single team or by multiple teams.
One backlog per product, seeded by large to very large features or
One product per backlog, meaning that one product might have several components that are addressed by different teams. Think Microsoft Office (product suite) vs Microsoft Word, Excel, Outlook (components of the product that may be sold or purchased individually).
Here it would make reasonable sense to create and maintain separate backlogs for each sub-product or component.
In this case, a 1:1 ratio would be in effect whereby each backlog is owned and and managed by individual product owners. While the product itself remains in sole ownership of the product manager.
Feature ranking is based on business value, technical value, risk management, and strategic fit.
Highest ranked backlog items are decomposed during release planning into stories that can be completed inside an iteration. It is constructed and designed so a delivery team can provide estimates for each feature.
Prioritizing the Backlog
Agile teams rely on a prioritized backlog to guide their work. The most important work is at the top of the list, available for the team to start as soon as they are ready.
Less important work is ranked lower, and is elaborated only when it moves near the top of the list. As new work comes in that needs to be done, the product owner adds it to the backlog in the appropriate position so that the team always knows what work to start next.
When to prioritize
Rank the backlog continuously. Once you have committed to an iteration plan, you should not change the rank of those committed items. All other items can be re-ranked whenever you learn new information, usually in the form of feedback or information gathered from the team or stakeholders.
Techniques for prioritization
The product owner must rank the backlog, deciding which story is first, which is second, which is third, and so on.
Initially prioritize backlog items using a bucket scheme such as MoSCoW (must have, should have, could have, won't have).
Subsequently, you can individually rank each item in the backlog, so that the team can always start the prioritized stories. If a story contains various components that can be prioritized differently, consider breaking it down into multiple child stories.
Consider the following when prioritizing:
The value of the feature for the masses
The value of the feature to a few of the elite
Estimated time to implement
The impact it has on other stories
Risk and opportunity costs