Product Backlog Prioritisation
The Product Backlog is a living entity; new requirements will be added throughout the life of the
project and this action along with an evolving understanding of the solution being built and a changing
business background will necessitate continual reappraisal and reprioritisation.
Product Backlog Refactoring
-
Re-evaluate the priorities of the Product Backlog before the start of every Sprint
-
The Product Owner is responsible for the continual process of managing the Product Backlog
-
Before the start of every Sprint, break down large backlog items (weeks to deliver) into smaller units (days to deliver)
- The team need assist the Product Owner by helping to break down the backlog items and providing high level estimates
-
Never allow the Product Owner to go into the Sprint Planning meeting with an inadequate Product Backlog
Backlog Prioritisation Techniques
There are many ways to approach the process of backlog prioritisation; here we include just one possible example:
- Allocate up to 1,000 arbitrary units of value (Business Priority field) to each Product Backlog item,
choosing a unique value for each item
- Sort by the Business priority field - this is the default sort order for most of the Product Backlog Team Queries
- Allocate your planning time 60% to the top 20%, 30% to the next 20%, and 10% to the remainder
- The team then take the Business Priority value of each backlog item and use this as the
basis for the Delivery Order
- The team then make adjustments to the Delivery Order value to accommodate technical dependencies
The best interface for Product Backlog management is Excel, which for example enables you to perform actions like
copying all the Business Priority values into the Delivery Order fields in one go.