From Top 3 to Pie Chart

Ultimately, we want to have one product backlog for the whole organization in order to optimize value globally. However, the current reality is often lack of global priority, with many local backlogs. What could be practical next steps in order to gradually establish global priority?

I have been suggesting to start from defining top 3 or a priority guideline. However, I find it only effective in some cases. In this article, I'd like to explore the reasons and provide the alternative - pie chart.

Top 3

When suggesting to first define top 3, I have the below further changes in mind:

• from top 3 to top 10, 20... then the product backlog emerges
• have more people focus on those top items, thus, deliver more value as whole organization.

However, what actually happens is often different. Once top 3 becomes visible, it does increase the awareness about global priority. All related people do take these as highest priority. But there is little impact on others, whose work is not related to top 3. Why?

The organization is structured with various specialty areas, be it functions, components or customer domains. There are essentially many local backlogs, and the real work only follows the local priority. Even though everybody knows what top 3 items are, it doesn't change anything.

What is wrong with this? Aren't top 3 items already proceeding as highest priority? We need to step back and see the big picture. Looking at the whole development capacity in the below picture, we find that perhaps only 20% of people work on top 3, while the remaining 80% of people work on other things. What is the priority of other things? They are not in top 3, thus lower priority, but as they are being worked on, practically they have the same priority as top 3.

So, the defined global priority does not become the actual one by itself, and we need to respond to them - focus on getting them done as whole organization.

In my experience, the defined top 3 items are usually big. They are close to the traditional project size, i.e. 3 top items may be 3 top projects. Can we get the 1st item done before working on the 2nd and the 3rd, assuming that those items are already minimally valuable? If we are in smaller large-scale case (e.g. 30 people), it is feasible. This way, we evolve from top 3 to one backlog and one priority for the whole organization.

Nevertheless, there are limits to one backlog coming from both PO and team. Please see the full analysis in the series of "Limits to one Product Backlog". When we are in larger large-scale case (e.g. 150 people), we may end up with a few areas each having a few teams sharing one area backlog. Top 3 is not effective in guiding the priority across those areas, then comes pie chart.

Pie Chart

Pie chart shows how the overall development capacity is distributed, in terms of people or teams. Pie chart reflects the priority in a coarse granularity, and it is similar to an investment portfolio. The below picture is an example for an 150-people organization, distributed among 5 areas. Furthermore, same as product backlog, pie chart is also prone to change, but less frequently than backlog items.

So, instead of asking what top 3 are, we ask how you want to distribute your whole development capacity.

If you already structure your development organization into feature teams, then, the pie chart shows how many teams in each area. With the appropriate size of areas, this is essentially a snapshot of RAs (Requirement Areas). While the overall PO manages the life cycle of RAs, he could in practice be managing the pie chart.

If your current structure is not yet feature team based, the initial distribution is based on number of people. Then, we look for the opportunity to create the first RA - establish multiple feature teams and have them share one area backlog.

As the transformation of the whole organization into feature team based is a gradual process, it is very likely that in the middle of that change, we also need to change the pie chart. When that happens, we both move existing teams and establish new feature teams to reflect the priority change in the updated pie chart, until eventually pie chart becomes RA view.

Conclusion

Size matters. In smaller large-scale case (i.e. LeSS), we may start with top 3 - what are the most valuable work. In larger large-scale case (i.e. LeSS Huge), we may start with pie chart - how do we distribute our development capacity?