One of the main responsibilities of the Product Owner is managing the product backlog. It’s a team effort to refine the backlog, but the Product Owner is the one responsible for prioritising the backlog. This is a challenging job. Product Owners who are new in their role think the backlog only contains user stories for new features. But they soon find out this is only a part of the backlog. But what are the other parts? And how to find the right balance between them? This is where the ‘backlog prioritisation quadrant’ shows its value.
The backlog prioritisation quadrant is shown in the picture below.
The quadrant divides the backlog in new features, architectural innovation, support and technical debt.
The most obvious part of a backlog is new features (business focus, future oriented). This will be the main focus of the customer and most product owners as well. In their opinion only with new features real business value can be delivered. Everything else is less important and shouldn’t be something the budget is used for.
However, spending time on architectural innovation (technical focus, future oriented) can also provide business value and save the customer money that can be spent on new features. For example using a new tool for test automation to improve test coverage or a new development framework before it becomes redundant. A good development team makes sure there’s always time available to spent on architectural innovation and has the capability to explain the value in non-technical terms to the product owner.
The other two parts, support and technical debt, are related to the past. Support has a business focus and is used to offer customers the support they want for previously build products. Examples are bug fixes, minor enhancements to existing features or doing some maintenance work. This doesn’t seem like the most exciting work, but always locate some space on your backlog for this. That will definitely have a positive effect on your customer’s happiness.
The most difficult part to explain is technical debt, because it’s related to the past and has a technical focus. Technical debt is mostly seen as the problem of the development team and they should fix it in their own time. While badly written code is a form of technical debt, it doesn’t always mean it’s done on purpose. New insights or gained knowledge might be a reason to restructure the current code. The product owner might also be responsible for technical debt by encouraging the team to take a technical shortcut so the deadline is made. Technical shortcuts however can result in technical debt. In the end, spending time on decreasing technical debt will save the customer money. A product with lots of technical flaws will have a dramatic impact on the development teams velocity and prevents the team to work on new features.
I find the backlog prioritisation quadrant a very powerful tool that has many possibilities:
- By plotting all the user stories from you current backlog you can see how it’s divided. Do we have a lot of technical debt? Do we need to spent time on technical innovation? How much time do we really have for building new features?
- By adding percentages of the current and the desired situation you can have a discussion with the team and/or stakeholders on how to get there.
- It shows the product owner and stakeholders it’s not only about new features but you should take the other three parts also into account. It can be used during the sprint review or the refinement to discuss the priorities for the upcoming period.
I got the idea for the backlog priorisation quadrant from Growing Agile. They provide some valuable material that offer inspiration for Agile/Scrum trainings. Feel free to use the quadrant and please share your findings in the comments on this blogpost. I am very curious to see whether this technique will give you other benefits than the ones mentioned above.