Limits to one Product Backlog - 4

In the previous article, we explored one of the two limits from PO - the fake limit on clarification. In this article, we shall explore the other limit from PO - the real limit on prioritization.

Real limit on prioritization

Besides the limit on clarification, the other limit is PO's capability on prioritization. Unlike that team can do the clarification, thus PO's capability on clarification is a fake limit; it is generally considered that PO has to do the prioritization, thus PO's capability on prioritization is a real limit. This can be illustrated as the below balancing loop.

The dynamic on prioritization is similar to the one on clarification. PO's capability on prioritization can be metrified as "#items a PO can prioritize". The gap between the capability (e.g. a PO can prioritize 100 items) and the need (e.g. there are 200 items in one PBL) creates the anxiety for the PO. The most common response is also to increase the number of PBLs, and accordingly, the number of POs, so that each PO needs to prioritize fewer items, as there are fewer items in each PBL.

When we put these two limits together in the same diagram as above, we find that the main difference lies at which limit comes to effect first. In other words, which number - "#items a PO can prioritize" or "#items a PO can clarify" - is lower? As we know, we need to clarify those items in order to prioritize them. However, the extent for clarification is different when our purpose is for prioritization vs. for delivery. We need to clarify more when for delivery, thus, "#items a PO can clarify" is lower than "#items a PO can prioritize". For instance, a PO can clarify 50 items, but can prioritize 100 items.

In fact, this is the main assumption behind the magic number "8" defined in LeSS and LeSS Huge frameworks. We assume that the limit to one product backlog comes from PO's capability on prioritization, i.e. a PO can prioritize 100 fine-grained items. Other assumptions are: 1) how fine-grained are they? 4 items per sprint per team; 2) how far do we look ahead, i.e. for how many sprints do we keep those items in fine granularity? 2-3 sprints. Based on these, roughly we need to prioritize 12 fine-grained items for one team. Then, 100 / 12 = "8", that is the whole logic.

Prioritize together

However, in our previous experience, we had 12 teams sharing one product backlog, which clearly broke the limit. How did we achieve that? The key lay at FOs (Feature Owners).

"FO tries to maximize the ROI for the feature. He maintains an overview for the feature, prioritizes backlog items inside it, together with APO decides whether to continue the development of this feature or move to other features."

In fact, with FOs participating in the prioritization, we increased our capability on prioritization. The PO together with a group of FOs could prioritize more items.

In our practice, the PO led the prioritization in coarser granularity, while the FOs in finer granularity. However, they prioritized together still in one product backlog, and still inspected & adapted on sprint basis to globally optimizing for customer value. During the regular meeting among the PO and FOs, the PO set the overall priority in coarse granularity, like a priority guideline; while the FOs shared the priority inside respective features in fine granularity and made suggestions about which part of the feature should be done now and which part could be done later, comparing to other features.

There are other ways of prioritizing together. For instance, PO provides the vision and facilitates the prioritization with FOs. This way, they co-create one priority, while the vision acts as the guideline for prioritization.

In the above left diagram, it shows the change over time on how much PO and FOs decide while prioritizing together. Initially, PO decides the priority all by himself. Then, PO steps back and creates space for FOs to decide. In the end, it is possible that PO mostly facilitates, while the prioritization is done mostly by FOs. PO still owns product vision, but the capability on prioritization increases when FOs decide more in prioritization.

In the above right diagram, FOs is replaced with teams. In the previous article, we explored how the FO role may transition from an external role designated by PO or manager to an internal role emerged through team self-organization. When this happens, it becomes teams or part of them who prioritize together with PO.

According to the LeSS guide "Prioritization over Clarification", PO should mostly focus on prioritization, but delegate detailed clarification to teams. However, this does not necessarily mean that only PO can prioritize. When PO and teams prioritize together, the capability on prioritization becomes less limiting.

Further thought

So far, we have explored the limits from PO, including both the fake one on clarification and the real one on prioritization. Even for the limit on prioritization, we can make it less limiting by prioritizing together.

However, the vision is still provided by PO. Is the capability on visioning an ultimate limit from PO? We have actually explored the topic of shared vision on product. It is possible, though hard, to co-create the vision! While vision provides the guideline for prioritizing together, prioritizing together also enables shared vision. So, there seems not any absolute limit from PO towards one product backlog.