July 2021 Archives

Limits to one Product Backlog - 3

What are the limits to one PBL (Product Backlog)? Two major areas are from PO (Product Owner) and team, respectively. We shall first focus on the limits from PO. When people claim that it is impossible for one PO to manage one PBL shared by many teams, there are actually two different limits behind. One is on clarification, based on the assumption that PO needs to clarify items in the PBL; the other is on prioritization, based on the assumption that PO needs to prioritize items in the PBL. We shall focus on the first limit in this article, and the second one in the next article.

Fake limit on clarification

One PBL leads to optimal organizational adaptiveness, however, it is limited by a few factors, one of which is PO's capability on clarification. This can be illustrated as the below balancing loop.

Limits to one PBL 3 - 1.jpg

PO's capability on clarification can be metrified as "#items a PO can clarify". The gap between the capability (e.g. a PO can clarify 50 items) and the need (e.g. there are 200 items in one PBL) creates the anxiety for the PO. The most common response is to increase the number of PBLs, and accordingly, the number of POs, so that each PO needs to clarify fewer items, as there are fewer items in each PBL. If we accept this logic, probably one PBL can only be shared by no more than 2-3 teams.

However, this is a fake limit, as we don't need to let PO clarify all items for teams. Instead, teams can clarify items for themselves, while PO focuses more on the prioritization. This is described in the LeSS guide "Prioritization over Clarification", and can be illustrated as the below balancing loop.

Limits to one PBL 3 - 2.jpg

Team's capability on clarification is the key factor to make it work. It is common that teams at first lack the product knowledge and skills to do the clarification well. Does this mean that it is at least temporarily a real limit to one PBL? Not really, because even in that case we can still keep one PBL.

Keep one PBL

When teams are not ready to take over the clarification immediately, we can still keep one PBL but have some people help the PO on clarification. As those helpers are only for clarification, they don't maintain separate PBLs. Thus, they are not POs, but more like FOs (Feature Owners) described in the previous article. The below part is related to clarification.

"FO does high-level clarification and leads the splitting of the feature into smaller backlog items. Then, he collaborates with teams during PBR (Product Backlog Refinement) to do detailed clarification and define acceptance tests for those backlog items."

This approach can be illustrated as the below balancing loop.

Limits to one PBL 3 - 3.jpg

Instead of having multiple PBLs, we keep one PBL, but have a few FOs to help the PO on clarification. However, please keep in mind that teams will at least participate in the detailed analysis during PBR.

Where do those FOs come from? Let's look at two scenarios, one used to have "team PO" maintaining a separate PBL for its own team, the other without.

  • In the first scenario, "team PO" may not be willing to join the team immediately for valid or invalid reasons. Under this circumstance, we can turn "team PO" into FO, and get rid of its separate PBL. Meanwhile, they still lead the clarification through their product knowledge and skills. This creates one PBL right away, as well as makes a next step towards the vision of PO on prioritization and teams on clarification.
  • In the second scenario, some members may take the lead in actively developing the product knowledge and skills for effective clarification. Is it necessary to introduce FO as a new role, when there was no "team PO" before? Probably no. In general, this relates to the interaction of FO vs. team in clarification.

Feature Owner in transition

Is FO inside or outside team? In our previous experience, it was not clearly defined, but hinted as being outside team. It had the negative impact on the rest of teams.

Limits to one PBL 3 - 4.jpg

The danger with the FO role is shown in the above "shifting the burden" dynamic. FO approach in B1 is the short-term symptomatic solution, while team approach in B2 is the long-term fundamental solution. Furthermore, there is an addiction R loop that drives our dependency on the FO solution. B2 represents the vision, without shared vision, we will stick with B1 forever.

Once we agree on the shared vision, we leverage by decreasing B1 as well as increasing B2. The below are a few possible next steps in tactics.

  • Make FO a role inside team, and let team decide who takes FO for which feature (decrease B1)
  • Facilitate teams to learn and grow product capability during PBR led by FOs (increase B2)
  • Have different team members take FO for various features (decrease B1)
  • Try no explicit FO for one feature and let teams self-organize to clarify (increase B2)

Should we remove the FO role eventually? In fact, I am fine if team decides to keep FO as a dynamic role inside team. As long as team members take FO at various time for various features through self-organization, this role is not any more limiting.

Limits to one Product Backlog - 2

The previous article was written in an analytical manner, while in this article I will supplement it with an experience during the time of Nokia Networks. As it happened more than ten years ago, some details may not be as accurate as I would like them to be, but I hope that I still capture the essence. Moreover, I will add my reasoning as an afterthought, while the reality is that we did not reason thoroughly about those changes when they were introduced. Today, I would suggest to first reason about the change by doing system modeling, then get back to the model after the change for learning and adaptation.

One Area

It was an area called TT (Traffic & Transport) in a 3G-based network product. There were 4-5 areas like that in the whole product. We had 12 teams, one area backlog and one APO (Area Product Owner) in TT.

This happened before LeSS had its name, so we didn't actually call it RA (Requirement Area), and there was also some difference from RA. However, it matters little for understanding the changes if you just treat it as a RA, or even a product. All the following changes happened within the scope of TT area.

Two main changes happened, one after the other. Some tensions were developed before them, and the most obvious one was the workload of the APO. As you can imagine, it is a challenge to have one APO for this size of an area.

Feature Owner

APO was overloaded, and he desperately needed someone to help. We introduced the CIO (Content Item Owner) role to lead the development of Content Item, which was just a fancy name for big feature, its development mostly across multiple teams and many sprints. To ease the cognitive load, I will use more generic term FO (Feature Owner) for this role, but keep in mind that those features are rather big.

There are two aspects defined and emerged in this role.

  • Product leadership

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.

FO does high-level clarification and leads the splitting of the feature into smaller backlog items. Then, he collaborates with teams during PBR (Product Backlog Refinement) to do detailed clarification and define acceptance tests for those backlog items.

  • Technical leadership

Unlike PO, FO also exerts technical leadership by organizing the group of senior developers from teams for joint design of the feature and facilitating the coordination of teams working on the feature.

Initially, FO was just a part-time role, and he was still working in the team as team member. Was FO inside or outside of team? I believe that it was not clearly defined, and the team boundary was blurred after the role was introduced. Who selected FOs? By APO and line managers, not by teams themselves. This hinted that it was a separate role outside team.

The part for product leadership was similar to the mode of PO on feature described in the previous article. Teams would work with different FOs as they developed different features.

The part for technical leadership happened more accidentally than designed. When the feature spanned multiple teams, teams simply looked for someone to lead across teams, instead of relying on teams' self-organization.

Over time, some FOs became full-time, as they worked on feature by feature, and spent less and less time working in the team, until none.

How on earth should we understand this role?

  • First, FO is not really PO, because their prioritization is limited in the feature, thus they have limited influence on the overall ROI. In fact, there is no such thing as PO on feature. In that case, the most essential part of the PO role - identify the valuable features - has already gone.
  • Second, FO's main focus is on high-level clarification and splitting, while they work together with teams on detailed clarification to define acceptance tests during PBR. In this regard, it is similar to the BA (Business Analyst) role, which should have been incorporated into teams. Furthermore, it is more like the SE (System Engineer) role, since he works on both product and technical sides. This is not surprising at all, as SE is part of the status quo, while the force to bring us back to status quo is always lurking.

Let's see the subsequent effects from introducing the FO role in the area.

  • How many product backlogs were there in the area? Still one area backlog and one priority decided by the APO. The inspection and adaptation around the area backlog still happened at every sprint in TT.
  • A group of people (those FOs) in the area had actively developed product knowledge and leadership. Regardless of whether they would move towards APOs or back to teams, the capability improvement was real.
  • The rest of teams got less space to develop their product knowledge, and the transparency decreased as well, when APO started to work more with FOs, rather than directly with teams.

Sub-Area Product Owner

At some point in time, we introduced the sub-APO role. We had mainly two sub-areas: TT-IP for IP-based Traffic & Transport, and TT-ATM for ATM-based Traffic & Transport. Back then, some people had taken the FO role for several features, and over time developed strong product leadership in a sub-area. In fact, they were already full-time FOs. Thus, it felt natural to take the next step and turn them into a more permanent sub-APO. It seemed also a natural career path leading to APO. Two additional factors influenced the decision of introducing the sub-APO role. One was that it would make the prioritization easier when we split into sub-areas, because the number of items became fewer in each sub-area. The other was that the reporting structure of teams also evolved into sub-area based, e.g. 6 teams specializing in TT-IP reported to one manager, while 6 teams specializing in TT-ATM reported to another manager. It all seemed quite fitting together.

However, this reflected our sloppy thinking at the time and the lack of deep analysis for the change. For example, we did not see clearly about its impact on the number of product backlogs and further on organizational adaptiveness.

How many product backlogs were there after introducing two sub-APOs for TT-IP and TT-ATM respectively? We tended to say still one, as there was still one APO for TT area. But if we looked at the situation more closely, we found that there were actually two backlogs. Regardless of whether those two backlogs were maintained as views in the same TT backlog or separately, the prioritization mostly happened within each backlog by the sub-APO. In addition, the coupled reporting structure made the teams attached to a sub-area, first psychologically then in ability as well. Subsequently, the more backlogs decreased the overall organizational adaptiveness.

Meanwhile, the need for FOs became less, especially when senior developers in teams could provide the technical leadership.

Summary

The overall journey looks like this: first only APO, next APO plus a few FOs, then APO and a couple of sub-APOs. When I was adding the reasoning for this experience, it felt somewhat messy. I guess that it is because our thinking at that time was somewhat messy. After clarifying the thinking over the years, I shall provide a new perspective in the next article.

About this Archive

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

June 2021 is the previous archive.

August 2021 is the next archive.

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