August 2021 Archives

Limits to one Product Backlog - 5

In the previous two articles, we explored the limits from PO (Product Owner) on clarification and prioritization respectively. In this article, we shall look at the limit from teams.

Team's capability on development

Similar to the limit from PO, we are also limited by team's capability on development, as illustrated in the below diagram.

Limits to one PBL 5 - 1.jpg

There is a gap between what team can do and what team needs to do, which creates the anxiety for team. In response to that, more PBLs (Product Backlogs) are created, thus, team needs to do less. This is the rough logic, but let's dive deeper.

How does team's anxiety increase #PBLs (number of PBLs)? There are actually two different scenarios, illustrated as two distinct links in the below diagram.

Limits to one PBL 5 - 2.jpg

  1. Teams decide on their own to only select certain items, which they are more capable of developing. This creates implicit backlogs.
  2. Teams raise their incapability of developing some items to PO, and PO agrees that they can only select other items. This creates explicit backlogs.

What may indicate team's capability on development? "#items a team can develop" is an option. Then, "#items in one PBL" actually means "#items a team needs to develop". Please note that #items here is not about velocity, but about variety.

In the series of "Number of backlogs and multi-learning", we described three types of specialization on various development capabilities - functions, technologies and customer domains. The one directly limiting one PBL is the development capability on customer domains, though, developing in various customer domains often requires different technologies and familiarity with different technical components. So, we may refine the variable into more narrowly focused "#domains in which a team can develop". The updated diagram is as below.

Limits to one PBL 5 - 3.jpg

Limited by team's development capability on customer domains, we create RAs (Requirement Areas), which are customer domains, to accommodate it. Thus, a team only belongs to one RA, and all teams in the same RA share one backlog and one priority. Though, the RA that the team belongs to will change, as the business and market change over time.

Sufficient but not necessary

Within the product (LeSS) and the RA (LeSS Huge), teams should have broad knowledge and are thus adaptive, being able to take any item from the one shared backlog. This sounds as if every team can develop any item. However, it is a sufficient but not necessary condition to keep one backlog and one priority.

There is a LeSS guide called "Prefer specialization in customer domain", and we applied it in an adoption at Huawei. The below diagram (slightly modified to emphasize the domain dimension) and text is an excerpt from the case study.

Limits to one PBL 5 - 4.jpg

"There were 4 noteworthy domains (such as extended OS, patching), and there would be 6 teams. We tried to support the two factors of broad knowledge (for adaptiveness) and good throughput, via (1) having each team able to work in at least 2 domains, and (2) with each domain having at least 3 capable teams. This change made each team still possible to have some level of specialization for throughput, while at the same time enabled the whole group to work on the highest priorities of the Product Owner, without distorted prioritization to meet the limited constraints of rigid teams that could only do one thing."

In this case, we had one product, containing 4 domains. In how many domains did a team need to develop? The simple answer would be 4, as it is likely that all high-priority items come from any of these 4 domains at one time. Then, any team should be able to develop in 4 domains. However, the constraint we set was at least 2 domains. How come? Because in actuality, there were at most 50% of high-priority items from any domain at any time, thus we needed at least 3 teams (half of 6 teams) capable of developing in each domain. This meant 4 domains * 3 teams / 6 teams = 2 domains, in which a team could develop.

If we look at the previous experience where we had 12 teams sharing one backlog, our teams were not homogeneous either. They specialized in smaller domains inside the RA, but when the specialization became limiting, we broke loose by having other teams learn in needed domains.

Postpone RA and keep one PBL

With the above insight, we discover an alternative to RA that would better accommodate the limit of team's development capability, in the sense that it would still keep one PBL. Let's illustrate this with an example.

Suppose that a product contains 4 domains (A/B/C/D), and there are 12 teams developing the product. Our limit is that each team can develop only in 2 domains.

1. Two RAs, two backlogs

The usual approach is to create two RAs, with 2 domains in each. For instance, RA1 with domain A/B and team 1-6; RA2 with domain C/D and team 7-12. This is illustrated as the table below. "x" in the table indicates that the team [1-12] can develop in the domain [A/B/C/D].

Limits to one PBL 5 - 5.jpg

2. No RA, one backlog

With the limit that each team can only develop in 2 domains, can we still keep one PBL? It depends. If one backlog means that every team needs to develop in any of these 4 domains, then, we can't. However, one backlog may only require 8 teams on A (i.e. at most 8/12 of high-priority items from domain A at one time) , 6 teams on B, 6 teams on C and 4 teams on D, then, we can. One possible configuration is illustrated as the table below.

Limits to one PBL 5 - 6.jpg

How do we put this into practice? We first try to understand what we need by asking PO - what is the estimated maximum percentage of high-priority items from each domain at one time? or what is the maximum number of teams that you would likely invest in each domain at one time? We essentially learn about the extent of adaptiveness we need, in terms of how many teams should be able to develop in each domain.

Then, we turn that into the constraint about how many domains in which each team needs to develop. This becomes the input for self-designing team workshop. The constraint may be met through composing teams appropriately or following learning or both. In either case, we mark the team as "can develop". We may make the further distinction between "can develop/skilled" and "can develop/learning". With a new domain emerged, not a single team can, or every team can! Teams decide which teams will first jump in to develop capability in that domain. All those teams are in the sate of "can develop/learning". Nevertheless, do not over-complicate it, as this is just a snapshot, and it is evolving constantly.

Conclusion

Till now, we have explored the limits to one PBL with the following topics.

  1. PO on team or PO on feature?
  2. Experience with FO and sub-APO
  3. Limit from PO on clarification
  4. Limit from PO on prioritization
  5. Limit from teams on development in domains

In the end, I would like to give you a challenge - experiment to have 10-15 teams share one PBL with the ideas from this series. I look forward to your sharing of experience and learning!

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.

Limits to one PBL 4 - 1.jpg

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.

Limits to one PBL 4 - 2.jpg

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.

Limits to one PBL 4 - 3.jpg

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.

About this Archive

This page is an archive of entries from August 2021 listed from newest to oldest.

July 2021 is the previous archive.

Find recent content on the main index or look in the archives to find all content.