Limits to one Product Backlog - 6

I have written the series of "limits to one product backlog" for a while, and the recent observation and thought triggers me to write another one, which is an addition to the 4th article. We shall elaborate on the capability of prioritization as a limit.

The above diagram was described in the previous article. It showed that the challenge of prioritization comes from the number of items, but didn't deep dive into what specific challenges are associated with the increasing number of items in one backlog. And we dig deeper in this article.

Quick fix for the incapability

As you know, the splitting of teams for different work - thus more backlogs - is common in large-scale product development. There are various reasons, mostly related to various specializations from both team and PO. However, I notice another one more and more often, which is related to the incapability of prioritization. Let me illustrate with a few examples.

• A team used to work for both new development and maintenance. It turned out that maintenance work was always urgent, causing short-term effect; thus, new development was left behind, causing long-term effect. The solution? Let's split into two teams, one for maintenance, and the other for new development. This is a quick fix for our incapability to prioritize between short-term and long-term.
• A group of teams used to work in one priority for multiple groups of business stakeholders. It turned out that every now and then there was escalation from certain group that their requests were not fulfilled. The solution? Let's split into teams, each team for one group of stakeholders. This is a quick fix for our incapability to prioritize across various stakeholder groups, i.e. between local and global.
• A group of teams used to work in one priority for multiple product areas. It turned out that there was an endless fight for priority among areas, indicating a lack of shared vision and global priority. The solution? Let's split into teams, each team for one product area. This is a quick fix for our incapability to prioritize across various areas, i.e. between local and global.

In fact, these quick fixes accommodate for our lack of whole product focus while prioritizing, and our lack of systems thinking to optimize in the long term and at the global scale. So, to make this limit more specific, I update the previous diagram as below.

The limit is our capability on global prioritization in both time and space. The solution is to reduce item diversity in one backlog - be it all maintenance items, or all items from one business group or in one product area.

Why is this limit so pervasive?

When I start to notice this incapability, I find it rather pervasive. Often, we can't proceed towards one product backlog or one area backlog with broad scope, because it is difficult to find a suitable PO or APO. Many people are used to prioritizing inside domains and projects, thus, don't develop the capability to prioritize globally. This incapability doesn't happen by accident, and there is a deep why.

Facing the challenge from much diverse items, PO's anxiety goes up. We can either do the quick fix by increasing more local backlogs (B1-loop), or learn to eventually increase PO's capability on global prioritization (B2-loop). Because it takes longer for B2-loop to take effect, there is another (invisible) reinforcing loop - a vicious cycle - embedded in the two balancing loops.

• the higher PO's anxiety
• the more local backlogs
• the less item diversity in one backlog
• the lower PO's anxiety
• the less learning on global prioritization
• the lower capability on global prioritization
• the higher PO's anxiety

In short, it is not only "we are limited by our capability on global prioritization, thus having more backlogs", but also "we have many backlogs, thus, causing our incapability on global prioritization".

Conclusion

Let's conclude by looking at the leverage. As you may have noticed, the above dynamic reflects the archetype of "eroding goals". The leverage is to focus on maintaining or elevating the "goal" - PO's capability on global prioritization. And how? through learning and practicing the prioritization in a more global backlog with peers. Instead of creating multiple local backlogs to accommodate for the incapability, we introduce one global backlog to drive the learning thus increase the capability.

Therefore, do not delay the introduction of one backlog, start with one backlog and have a group of people take shared responsibility to prioritize globally. As they learn, the capability of prioritization doesn't limit any more.