Ordering the Product Backlog
Basic
difficulty
Stage 2
Agile IQ® Level
Prioritisation
Practices
Scrum
Framework
Introduction
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the agile team. Unfortunately, ordering Product Backlog items by their “priority” leads to suboptimal market value and reduced return on investment.
The Product Owner needs to consider the entire backlog when ordering Product Backlog items, to optimise value.
Order the Product Backlog, don't prioritise
To prioritise a list means to order its items by their importance relative to each other.
Unfortunately, priorities drive pair-wise comparisons (by English language definition) of items on the list. Think of using bubble sort to prioritise the Product Backlog: compare the top two items and interchange them if they’re in the wrong order, and then move on to the next pair, and keep cycling through the list until everything is in its place. Prioritisation and sorting go hand in hand. All the comparisons are local. This process is analogous to local optimisation.
The focus on ordering (over "prioritisation") underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximises value.
The Product Goal
The ordering of the Product Backlog should be done in such a way so that it delivers against the commitment of the Product Goal.
The Product Backlog should emerge to define what will fulfil the Product Goal.
Techniques
- Dude’s Law – why is the item needed versus how much time and investment from the team will it take to deliver? This technique was popularised by the late David Hussman.
- Return on Investment (ROI) – which items will bring the biggest returns for the lowest investment of the team’s time.
- Cost of Delay – which items will deliver the highest value and will lose value if we don’t deliver them sooner rather than later.
- Impact and Risk – relative to each other, which of the items represent significant risk if they’re not delivered now.
- Size vs value – which items in the Product Backlog are small and so their value can be realised now.
Things to watch out for
Governance
The Product Owner is accountable for managing the Product Backlog and its order, not a committee.
Adapts as you learn
The Product Backlog should be continually refined and re-ordered over time as the Product Owner learns more about what customers value, what stakeholders need, and what the market says it needs.
Evolves
The Product Backlog should never be static. Everyone should be able to contribute to the backlog, but the Product Owner is still accountable for optimising its order for value.
How fast can you pivot to change?
An agile team's ability to respond to change depends on how well the whole team understands its product reflected in the items in the Product Backlog.
References
1. Overeem, B. (2017) Myth 5: In Scrum, the Product Backlog is prioritized
2. Schwaber, K., & Sutherland, J. (2020) The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game.
3. Reinertsen, Donald (2009). The Principles of Product Development Flow. ISBN 1-935401-00-9.
All fields are required.
