Product Backlog
Basic
difficulty
Stage 2
Agile IQ® Level
Artefacts
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.
Why is the product backlog important?
The Product Backlog contains all of the work for the team. When there is no Product Backlog, or if it is poorly managed:
- Productivity suffers.
- The team lack focus.
- Transparency about future work is poor.
- Work can’t be prioritised.
- The value of work relative to product goals or strategic objectives becomes unclear.
Managing the Product Backlog is the Product Owner's primary job
Product Owners aren't "Agile Business Analysts". Their role doesn't encompass eliciting requirements for the team to work on. Its strategic focus requires the Product Owner to be proactive in translating the strategic outcomes of the product into a roadmap that decomposes into a single list of work for the team. While the Product Owner is accountable for making this happen, they don't necessarily have to do all the work themselves. This is why the Product Owner is part of the Scrum Team.
anti-patterns to avoid
"Buckets"
When there are multiple lists of work, the team lacks focus. At no point in time can anyone, including stakeholders, be clear about what work the team will do next.
Impact: Lack of focus.
What to do: The Product Owner should organise all the work into ONE list with the help of the rest of the team.
Only One Sprint of Work
When there is only a Sprint or two worth of items in the Produc Backlog, the team becomes very reactive regarding stakeholder needs. Managers begin to look for work for the team to be busy without consideration of whether that work is of value.
Impact:Team turns into a 'feature farm'. Team is highly reactive.
What to do: Use the Product Goal to determine what work is of value. The Product Owner should work aggressively to understand the future roadmap of work, product objectives, and turn it into the Product Backlog.
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.
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 ... A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Techniques for Ordering the Backlog
- 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.
Actions
Put aside 10% of the capacity of the team for Backlog Management activities.
In a Backlog Management session:
- Discuss the Product Goal.
- Use the Roadmap technique to sort features and associated work into blocks of one month for the next 3-months. Sort work beyond that horizon into blocks of quarters months. Any work that is further than 2-years away, sort into blocks of 1-year.
- Use Dot Voting on the work in the first month with the team and stakeholders. Each dot represents the items that have the most value to the Product Goal as it is understood today.
- Sort the items in month one according to the number of dots into a single, rank ordered list. Where there are items with the same number of dots, repeat the Dot Vote on each set so that the items in the set conform to the single, rank ordered list criteria.
- Repeat for months 2-3.
- Repeat for the work in the next quarter.
Ensure the remaining items also go into the Product Backlog. They should be in a general ranked order of value, knowing that as more is known about these items they will get re-sorted in the near future.
The Scrum Master should be coaching the Product Owner
A Scrum Master's role is to coach the Product Owner on good techniques for agile product management, including how to manage the Product Backlog. This doesn't mean the Scrum Master manages the list like a Delivery Manager. Instead, they coach the Product Owner to do this themselves, help the team to help the Product Owner, and facilitate workshops that engage stakeholders to help the Product Owner.
References
1. Overeem, B. (2017) Myth 5: In Scrum, the Product Backlog is prioritised.
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.
