How to better balance your backlog
Without imposing or enforcing anything
According to the Scrum Guide, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The main mechanism that the Product Owner has to achieve this, is ordering the backlog.
If you are a Product Owner, you may ask: how do I order the backlog in such a way that the Scrum Team works on those items that will maximize the value of the product?
Feedback from stakeholders during the Sprint Review is invaluable here. Without that, you’re just going on assumptions. But even with this feedback, it is easy to get it wrong.
One common mistake I see is imbalance.
Imbalance happens when a Product Owner prefers new functionality over fixing defects; or fixing defects over structural code improvements (e.g. refactoring); or product development over validating assumptions.
None of this is bad, and these trade-offs must be made all the time. It becomes bad when the trade-off is almost always in favour of one.
While Product Owners make trade-offs all the time, not all Product Owners are aware of trade-offs between different categories of backlog items. That’s when introducing a simple tool like backlog quadrants can help: to create awareness of different categories of work and the need to balance it.
How to use backlog quadrants
My preferred approach is:
- Introduce the concept
- Calibrate it for the team/product
- Start using it, then inspect and adapt
Below is a short explanation. Contact me if you want to know more. I tried writing a more detailed description but it didn’t make good reading.
Introduce the concept
As a Scrum Master I like to introduce backlog quadrants in a workshop. You could also do it during refinement, in a retrospective, or 1-on-1 with your Product Owner. First I explain why I want to talk about this (e.g. because developers have said they feel there is an imbalance in the work).
The rest of my explanation would go something like this:
Backlog Quadrants is a way to categorize product backlog items, i.e. upcoming product development work. The vertical axis makes a difference between functional and enabling items. Functional refers to stuff that users and stakeholders want. Enabling refers to stuff that we need to do to enable the functional part. In previous versions I called it Technical. This is the foundation or infrastructure that you need.
The horizontal axis distinguishes between new things that our product doesn’t yet have (Create) and updates, changes or fixes to what is already there (Maintain).
The combination of these 2 axes gives us 4 quadrants. 4 categories of backlog items. For short I sometimes label them CF, CE, MF and ME.
For both axes there is a grey area. For example: when is something a change to an existing part of the product, and when is it something new? Most items will clearly fit into a category, don’t worry too much about the ones that could go either way: pick whatever feels best.
Calibrate it for the team or the product
This is quite abstract, so the next step is to collect examples and map them onto the quadrants. You can do that at the team level. If you have multiple teams working on the same product it could make more sense to do this at the product level.
You could look at actual items on the product backlog, or just think up examples. Help the team to place items in the right quadrants, it will take some getting used to. Some items may need to be split. For example: “Test Automation” goes in the bottom half, for Enabling items. But creating new Test Automation would go bottom right, whereas maintaining existing test sets and test data is something that fits the bottom left quadrant.
Other items may be too large or not specific enough. For example, “Minimum Viable Product” is a whole set of backlog items. Most or all of those items would go on the right side (Create), but I would expect a mix of functional and enabling items in there.
Start using it, then inspect and adapt
Now that you have some agreement on what kind of work goes into each category, it is time to start using this to better balance the backlog. As always, there are many different ways to do this. Here is an example.
Look at the backlog items of the past 3 sprints, categorize them and figure out what the average distribution was over the 4 categories. You can lump the 3 sprints together, or show the trend over 3 sprints. You can count items, or you can sum story points, whatever makes most sense to you.
This will give you a baseline. Now facilitate a discussion about the baseline. If there was a feeling of imbalance, does that show up in the numbers? Are we all agreed that this is “bad”? Can we come to a suggestion for the next sprint?
If, for example, the Scrum Team agrees that too little attention has been given to the “Maintain Enablers” category, then look how to remedy that. Are there items on the Product Backlog that fall in this category that we could prioritize? Do we need to create and refine some new items? How much attention should we give to it?
I prefer not to work with fixed buckets: 40% for CF, 20% for … etc. Often, just being aware of the categories and the need to balance them is enough. I do quite like to measure and reflect. Once we’ve identified what goes into each category, we could label backlog items and easily measure and visualize the distribution over time. Good to look at that every now and then, in a retro or during Sprint Planning.
In summary
I’ve found Backlog Quadrants a useful tool to address imbalance in the type of work that is prioritized. It doesn’t enforce anything; it just enables you to visualize the imbalance. By doing so, it promotes discussion and allows the Product Owner to adapt if needed.
Credits
I first came across this concept while working as an Agile Coach at Jumbo Supermarkten: during one of the first Product Owner Communities of Practice a PO presented a version of this (with different labels and a different storyline). I regret I can’t remember who it was. I then started using it and evolving it. At Philips Research and recently at ABN AMRO it sparked more interest and I decided to write a post about it.
