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 spend 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 your current backlog you can see how it’s divided. Do we have a lot of technical debt? Do we need to spend 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 prioritisation quadrant from Growing Agile. They provide some valuable material that offers inspiration for Agile/Scrum training. Feel free to use the quadrant and please share your findings in the comments on this blog post. I am very curious to see whether this technique will give you other benefits than the ones mentioned above.
If you liked this article, please like DM Spot FB page, Twitter or LinkedIn and be notified when a new article is published.
If you want to learn more about Scrum and Agile software development then this Agile Masterclass: Scrum for Product Owner and Scrum Master is the perfect thing for you:
