The Odd-e Blog

The Authors

The Necessity for a Product Group Owner

There are a few teams each having its own PO (Product Owner), is there a need for an overarching PGO (Product Group Owner)?

Blog - PGO 1.jpg 

I have recently encountered two different configurations, and let's explore them one by one.

1. Teams are responsible for elements in the product 

Blog - PGO 2.jpg

In the above configuration, each team is only responsible for elements in the product, but not the complete product. Is there a need for a PGO? 

Blog - PGO 3.jpg

Those element teams are essentially component teams. Their POs are not real POs, as they are not able to maximize customer and business value on their own. So, the answer would be yes - an overarching PGO is necessary for the complete product. Meanwhile, those POs should not exist. Then, isn't the PGO really the PO? Yes, indeed. We don't need a PGO, but a real PO. Therefore, in this configuration, there is one PO with three element teams (illustrated in the above diagram). While there is one product backlog for the complete product, however, as those teams can only develop elements, some product backlog items will inevitably be across teams. You may consider an alternative structure - feature team.

2. Teams are responsible for complete products

Blog - PGO 4.jpg

In the above configuration, each team is responsible for a complete product. The difference from the last configuration is that POs here are responsible for maximizing customer and business value on their own. Is there a need for a PGO? 

Blog - PGO 5.jpg

The first answer would be no (illustrated in the above diagram). Each PO works with one team to develop own product independently. There is no need for an overarching PGO, but only three POs working in parallel. 

Blog - PGO 6.jpg

What if we have five teams, how many teams should work on each product? Each PO can't decide on its own. It is possible that they form a committee to deal with this kind of portfolio question, but it is more common to introduce an overarching role to decide. So, the second answer would be yes (illustrated in the above diagram). The PGO is essentially a product portfolio manager. He together with POs regularly reviews the portfolio and adapts. For instance, the portfolio this year is: product 1/two teams, product 2/two teams, product 3/one team; but the portfolio next year becomes: product 1/three teams, product 2/one team, product 3/one team. Within each product, POs still have the complete authority to decide the work priority and are responsible for maximizing value. 

Blog - PGO 7.jpg

When those portfolio decisions need to happen more frequently, we can move toward one shared product backlog, so as to embrace the change on sprint basis. Then, the third answer would be yes - an overarching PGO is necessary for the overall product group. Do we still need those POs? Because there is only one product backlog and one priority, we don't. In LeSS, this is called expanding the product definition. Product group becomes the expanded product. The PGO really is the PO (illustrated in the above diagram).

One last question, what is product group? In some cases, those products in the product group sell independently. Product group is just a group of independent products, but it optimizes the value of the whole group by prioritizing together within the product group. In other cases, the product group sells the system, consisting of those products. In fact, each product becomes an element in the complete system. This goes back to the first configuration.


Different rules in LeSS and LeSS Huge

"We have 5 teams. We are doing LeSS, and we have 3 APOs (Area Product Owners)." Wait, this is NOT LeSS!

Motivated by this kind of common misunderstanding, I am writing this article to describes the different rules in LeSS and LeSS Huge, and why they are different.

LeSS vs. LeSS Huge

First, what is LeSS? I have to admit that the word LeSS is an overloaded term. It means several things. Let me try to clarify.

  • LeSS as a system

I can't actually find a proper word to describe LeSS in general, including experiments, guides, rules and principles, as shown in the LeSS complete picture. I will just call it a system.

  • LeSS as a framework

When we say that "LeSS is Scrum applied to many teams working together on one product", it probably refers to LeSS also as a framework, as Scrum is a framework. Then, LeSS framework is only part of LeSS system - the rules. What makes it more confusing is that when we say LeSS framework, it can again mean two different things.

    1. LeSS framework as a whole, including both smaller LeSS and larger LeSS Huge frameworks
    2. Only the smaller LeSS framework

These different meanings behind the word LeSS unnecessarily add the cognitive load for people learning about LeSS. I agree that we need to fix it, and will work on it further.

With the above clarification, we are in a better position to explain LeSS vs. LeSS Huge.

LeSS and LeSS Huge are smaller and larger frameworks respectively inside the LeSS system. The creation of LeSS frameworks was a response to novice practitioners in large-scale product development in need of something more specific than experiments to start their journey. This something became the rules in LeSS system and they form the two frameworks.

When we say that "this is or is NOT LeSS" or "we are or are NOT doing LeSS", we usually refer to the fact that we are or are NOT following the rules in the LeSS and LeSS Huge frameworks.

The larger LeSS Huge framework differs from the smaller LeSS framework in two significant ways. One is the introduction of RA (Requirement Area), and the other is using the evolutionary incremental approach in adoption. We will elaborate both.

1. Requirement Area

What are RAs? RAs are foremost area backlogs, which are subsets of the whole product backlog. Then, there is one APO and a few (usually 4-8) feature teams associated with a RA. You may learn more about RA from the following articles.

Why RAs in LeSS Huge? The introduction of RA is a response to those limits to one product backlog, especially the ones from PO. Please find more analysis from the following articles.

What is or is NOT LeSS?

LeSS vs LeSS Huge - 1.jpg

On one hand,

  • in the smaller large-scale context with 2-"8" teams, there is no RA, and all teams share one product backlog. This is LeSS!
  • in the larger large-scale context with "8"+ teams, there are RAs - area backlogs, and a few teams share one area backlog. This is LeSS!

On the other hand,

  • in the smaller large-scale context with 2-"8" teams, there are RAs - area backlogs, i.e. not all teams share one product backlog. This is NOT LeSS!
  • in the larger large-scale context with "8"+ teams, there is no RA, i.e. all teams share one product backlog. This is NOT LeSS!

Objection! Isn't it great if all teams can share one product backlog even in the larger large-scale context with "8"+ teams? Yes, indeed. However, this is not following the rules in the LeSS Huge framework, thus NOT LeSS. Certainly, we can and should experiment on it!

2. Evolutionary incremental approach

What is evolutionary incremental approach in the larger LeSS Huge framework? This is in contrast to the all-at-once approach in the smaller LeSS framework.

LeSS rule: For the product group, establish the complete LeSS structure "at the start"; this is vital for a LeSS adoption.
LeSS Huge rule: LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.

Why evolutionary incremental approach? LeSS adoption is not simply process change, but deep organizational change. Thus, the change could be overwhelming in the larger large-scale context. Therefore, an evolutionary incremental approach is prescribed for LeSS Huge adoption. Please find more analysis from the following articles.

What is or is NOT LeSS?

LeSS vs LeSS Huge - 2.jpg

On one hand, 

  • in the smaller large-scale context with 2-"8" teams, we change the structure all at once. This is LeSS!
  • in the larger large-scale context with "8"+ teams, we change the structure with an evolutionary incremental approach. This is LeSS!

On the other hand,

  • in the smaller large-scale context with 2-"8" teams, we change the structure with an evolutionary incremental approach. This is NOT LeSS!
  • in the larger large-scale context with "8"+ teams, we change the structure all at once. This is NOT LeSS!

Again, NOT LeSS simply means that we don't follow the rules in the LeSS and LeSS Huge frameworks. It is encouraged to experiment on different approaches than what is prescribed.

Should we care?

Should we care whether this is or is NOT LeSS? Yes and no.

Yes. We should learn about the rules and their differences, more importantly, the reasoning behind them. Breaking rules with proper understanding is experimental, while breaking rules without proper understanding is simply ignorant.

No. Rules are for novice practitioners, while experiments are at the heart of LeSS. We can turn those "NOT LeSS" cases into meaningful experiments.

  1. In the smaller large-scale context, these are NOT LeSS: 1) RA, and 2) Evolutionary incremental approach. We can run the below experiments:
    • gradually increase the number of feature teams, thus change the structure with evolutionary incremental approach.
    • gradually decrease the number of backlogs, thus, still have multiple product backlogs (essentially RAs - area backlogs), until it is reduced to one product backlog eventually.
  2. In the larger large-scale context, these are NOT LeSS: 1) No RA, and 2) all-at-once approach. We can run the below experiments:
    • break the limits to one product backlog, and keep one (no RA) for 10-15 teams.
    • change the structure all at once to avoid parallel organizations in a 150-person organization.

These are both NOT LeSS (about following rules) and LeSS (about running experiments). We understand rules by adopting frameworks, then, break rules by running experiments!


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.


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.


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.


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.


Limits to one Product Backlog - 1

Recently, I ran across my old article "PO on team or PO on feature?" written about ten years ago, and found that it could be connected to the topic of limits to one product backlog. My thinking at that time touched some factors, but was still vague. Over the years, I have been improving my thinking on this topic, thus decide to write a series about it. Meanwhile, I also decide to take this old article as the first one in the series.

PO on team or PO on feature?

Product Owner is responsible for the product success. Product Owner is the single interface about team's work. In a single-team environment, PO works with that team constantly. It's all very clear.

However, in a multiple-team environment, it gets more complicated. It gets problematic to have one PO work with all teams in the product, when the number of teams goes too big. It leads to multiple POs working with different teams. There is still one PO at product level, who creates PO team with multiple POs. One PO will normally work with more than one team, but not all teams. Since one (big) feature may be developed by multiple teams together, two modes of relating PO and team come up.

  • PO on team

Fix the relation between PO and teams. For each PO, he constantly works with a few teams. Naturally, he manages the part of product backlog that relates to his teams' work.

  • PO on feature

Not fix the relation between PO and teams, but change it depending on the feature that the teams are working on. In this case, PO is responsible for features in the product. Which teams work on those features, PO works with which teams.

I have been suggesting PO on team all along, and I don't feel right about PO on feature. This post tries to clarify why, not only for you, but also for my own.

Benefits and problems of PO on feature

Let's first understand the benefits that PO on feature tries to get. There are mainly two.

  1. PO can specialize on part of the product and some features. For any team to be able to work on any part of the product, though ideal, it may not be feasible to beginning with. The same applies to PO. PO on feature makes it possible for them to specialize on part of the product.
  2. The overall feature can be managed by one PO, so that it reduces the coordination efforts among related teams.

The most obvious problem with PO on feature is, what if one team need to work on multiple features at the same time? If you would allow multiple POs to interface with same team, it would've brought back all traditional problems such as conflicting priority, partial allocation, etc.

But PO on feature does not have to be so. It can still be clear who is the PO for the team at any time. If team works on two features, the PO responsible for the more significant feature (in terms of value, size, etc.) will be the PO for that team in relevant sprints. Other POs need to work with that PO in order to get their stuff done in those sprints. Then, there will be PO switch, as team works on different features. Two POs may work together for transitional period, though only one of them is PO towards team at any time.

Is the above approach ok? I do not think so. There are two deeper problems with PO on feature.

  1. PO on feature creates strong focus on current feature, and does harm to the flow and long-term sustainability. If we'd like to get team high performance in the sprint, we need to make the feature ready before putting it into sprint. That requires progressively grooming the backlog and future features. If we'd like to get our release more predictable, we need to proactively address risks and uncertainties. That requires investing earlier by having spikes. If we'd like to sustain in delivering good quality product release, we need to lower the cost of change. That requires gradually paying off the technical debts from legacy. However, PO on feature favors short-term project thinking.
  2. PO on feature breaks the feedback loop, which is critical for learning and continuous improvement. It is less likely for PO on feature to learn from mistakes such as wishful commitment, sacrifice done, ineffective collaboration on requirements, etc., together with former teams.

In short, PO on feature often leads to imbalance between short-term and long-term thinking and focus, while for the role of Product Owner, it is not enough to be able to maximize ROI for one sprint or one feature, but do that sustainably for the life of product.

PO on both team and feature

How can we realize those benefits from PO on feature into the mode of PO on team? Working in product areas is the key.

On one hand, area should be big enough to accommodate most of features, even though those features are spread into multiple teams. Then, the overall feature is still managed by one area to ease the coordination. On the other hand, big enough area is still smaller than the whole product, thus, PO still possibly specializes in the area.

Regarding the number of teams one PO can work with, some say no more than 2, others say up to 10, my sweet spot is around 5. The size of 5 teams per PO is good for both having some specialization and easing the feature coordination.

Written in 2011.4


Follow value in defining RAs

[RA = Requirement Area; PBI = Product Backlog Item.]

In LeSS Huge, there is an additional scaling technique called RA. How to define RAs has confused many practitioners. This article tries to open a perspective.

By which dimension?

By which dimension do we define RAs?

We know that RA is customer centric. RAs are not defined from the dimension of technology or functions, but customer/business domains. However, there could be multiple customer views, which one is more appropriate?

Let's illustrate this question with the following example. The product for development is an e-commerce site. There are two dimensions for consideration while defining RAs.?

Follow value in defining RAs - 1.jpg

1. Process steps

Engage/Find/Buy/Followup are areas based on normal process steps for shopping customers.

  • Engage: engage customers for awareness, example PBIs - home page improvement, live streaming
  • Find: find desired product, example PBIs - product details page improvement, recommendation
  • Buy: buy product with ease, example PBIs - guest checkout, new payment method
  • Followup: provide after-sales service, example PBIs - product review, return handling

2. Cross-cutting

Standard/Special are cross-cutting areas serving different customer needs and scenarios.

  • Standard: standard product & process, example PBIs - home page improvement, product details page improvement, new payment method
  • Special: customized and personalized product & process, example PBIs - recommendation, live streaming, embossing, special packaging, gifting card, group gifting

In the cross-cutting dimension, a variant could be gifting area, grouping all gifting related PBIs.

As you can see, some PBIs fit in both dimensions, while other PBIs fit one dimension better than the other. Nevertheless, assuming that the skeleton is already in place, both process-step and cross-cutting dimensions could reflect customer value. Then, which one is more appropriate?

Think about PBIs

Let's return to the definition of RA. What is a RA? There are three aspects: 1) there is an Area backlog; 2) there is an Area PO; 3) there are 4-8 feature teams in the Area.

The first aspect is the fundamental one, and the other two are derived from it. Area backlog is a subset of the product backlog, and consists of a group of PBIs. Therefore, we can change the question from "by which dimension to define RAs" to "by which dimension to define PBIs".

The below is a snapshot of the product backlog for the e-commerce site.

  • product review
  • shipping status update
  • product details page improvement
  • new payment method
  • embossing
  • guest checkout
  • return handling
  • gifting card
  • group gifting
  • live streaming
  • AR try-on
  • home page improvement
  • ...

All PBIs are customer centric, but some are in the process-step dimension while others are in the cross-cutting dimension. We define PBIs by whatever dimension that carries value. The dimension of PBIs varies as value changes. Sometimes valuable PBIs appear in the process-step dimension, other times valuable PBIs appear in the cross-cutting dimension.

As RAs are essentially a group of PBIs, the same holds true for RAs. We define RAs by whatever dimension that carries value. In other words, we follow value in defining RAs.

The below is an example of how the RAs may evolve in the e-commerce site over time.

Follow value in defining RAs - 2.jpg

One last hint, when many PBIs are cross-RA (or have to be split into multiple RAs), it is the time to consider adapting the RAs.


Priority guideline

Our goal is to have one product backlog and all teams are working in its priority order to maximize the customer value. Our current reality is that each team has its own backlog and the so-called one product backlog is actually a collection of many backlogs.

A desired backlog

In the article "The path of least resistance towards one backlog", I suggested to create a desired backlog, which defines the priority that we want assuming no constraint. The actual backlog defines the priority we really follow by taking our constraints (e.g. this team can only do this work) into consideration. The gap between them creates the tension, which drives towards one backlog through reducing the number of backlogs, disrupting the current team boundary, and etc. However, we face two major challenges in creating the desired backlog.

One challenge is lack of motivation to do it, as the actual backlog is sufficient to keep teams busy. This indicates lack of organizational vision to maximize customer value and continuously improve. Therefore, the status quo with collection of backlogs remains and we even pretend that it is the one backlog.

The other challenge is lack of ability to do it, as what is important from the whole product perspective is difficult to answer. This indicates lack of shared product vision and lack of product leadership. A priority guideline could be a first step for the change.

A priority guideline

Comparing to a desired backlog, a priority guideline is easier to create while still serves our purpose, which is to create the tension necessary to drive towards one backlog.

What is a priority guideline? It is a priority list with the whole product focus. Here is an example.

  1. critical customer bugs
  2. product A release 2.0
  3. other customer bugs
  4. product B feature 12
  5. critical/major internal bugs
  6. customer project A1 (based on product A)
  7. product A release 2.5
  8. product B other features
  9. product A prototype based on new hardware architecture
  10. product C ...

In this list, there is more than one product involved. The reason is that many organizations define their products too narrowly and in LeSS they are all parts of a broader product definition.

In essence, the priority guideline is a backlog of coarse-grained items, which is dynamic and updated regularly to reflect the current priority. Moreover, this is a simplified version of desired backlog, rather than actual backlog, as the order of real work is not exactly following the one in priority guideline, which is anyway a guideline.

The key is ... the tension

We could further evolve priority guideline into desired backlog. We make the items in priority guideline more fine-grained, e.g. in terms of epics. By the way, in practice I try to avoid the term epic, as it often introduces unnecessary complexity and confusion. To me, those are all stories or just items, big or small.


On the other hand, it may be sufficient to let priority guideline drive towards one actual backlog, as the gap between priority guideline and actual backlog may already serve the purpose of creating the tension. Referring to the above picture from the "The fifth discipline" book, both desired backlog and priority guideline act as your vision, while actual backlog is your current reality. The gap between them creates the tension necessary to drive towards one backlog.

Product backlog and Area backlogs

Taking the above view, let's look at product backlog and area backlogs in LeSS Huge.

1. Simple case - items in product backlog and area backlogs have the same granularity.

Area backlog - simple.jpg

As the real work is done according to the priority in those area backlogs, the collection of area backlogs is in fact the actual backlog. Then, what is the product backlog? It is in fact the desired backlog. The gap between them is very visible, which creates the tension for change - requirement areas are dynamic!

2. Complex case - items in product backlog and area backlogs have different granularities.

Area backlog - complex.jpg

Similar to the simple case, the collection of area backlogs is the actual backlog, while the product backlog is the desired backlog. The difference is that items in product backlog are more coarse-grained than those in area backlogs. Nevertheless, it still shows the gap thus creates the tension for change. What's interesting is, as items in product backlog get more coarse-grained, the product backlog devolves into a priority guideline!


Percentage of people in special roles

In large-scale product development organization, %(people in special roles) is a good indicator for the degree of self-organization in teams.

Special roles in this measure are outside teams. There is no special role inside teams, as everybody takes the role of team member. Sometimes, the team may define "special roles" inside it, e.g. interface towards other teams. I consider this as their working agreement, because the team has the full authority to decide and change as they wish. The impact of having those internal "special roles" on their self-organization is a separate topic we may explore in the future. In this article, we focus on special roles outside teams.

Please be noted that %(people in special roles) is essentially the same as %(people in teams), as %(people in teams) + %(people in special roles) = 100%.

Its value in LeSS organizations

LeSS organizational design leads to low value in this measure. This is in line with the LeSS principle "More with LeSS" - the less (fewer) roles, the more responsible teams. Let's look at LeSS organization and LeSS Huge organization respectively.

1. LeSS organization

%people in special roles - LeSS org.jpg

Assume that

  • there is no undone department, which is the preferred case
  • there are 5 teams, 7 people in each, that is 35 people in teams
  • there are 1 PO, 3 SMs and 1 manager, that is 5 people in special roles

Then, %(people in special roles) = 5/(35+5) = 12.5%.

2. LeSS Huge organization

%people in special roles - LeSS Huge org.jpg

Assume that

  • there is no undone department, and no support as it is done by normal feature team
  • there are 20 teams, 7 people in each, that is 140 people in teams
  • there are 5 POs (PO team consisting of 1 overall PO and 4 APOs), 10 SMs (competence & coaching), 5 managers, that is 20 people in special roles

Then, %(people in special roles) = 20/(140+20) = 12.5%.

There is usually still undone department and support in LeSS Huge organization, and we consider them as people in special roles too, then its value is often higher in LeSS Huge organization.

Its impact on self-organization

Why "More with LeSS" - fewer roles leading to more responsible teams?

There are mutual effects between special roles and self-organization. Having more people in special roles outside teams leads to lower degree of self-organization in teams, which in return leads to more people in special roles. This is shown in the below diagram as a reinforcing loop. It could be either a virtuous cycle of leading to ever higher degree of self-organization in teams and ever fewer people in special roles, or a vicious cycle of leading to ever lower degree of self-organization in teams and ever more people in special roles.

%people in special roles 1.jpg

If we elaborate on the links in both directions, we get the below diagram. Having fewer people in special roles opens up more space for teams to self-organize, leading to higher degree of self-organization in teams. This in turn decreases the need for special roles, leading to fewer people in special roles.

%people in special roles 2.jpg

Of course, there are other factors too. We add a couple of more variables in the below diagram.

  • Job safety: when job safety is low, even if the need for special roles is little, people would still fight hard to keep their special roles so as to keep the job.
  • Coaching effectiveness: when coaching effectiveness is low, even if much space has been created for teams, they would still be unable to reach high degree of self-organization.

%people in special roles 3.jpg

By now, we have explained why %(people in special roles) would be a good indicator for the degree of self-organization in teams.

Its reality and goal

In reality, many large-scale organizations have a much higher value in this measure. Besides those in LeSS organizations, they may have more of the below special roles.

  • business analyst, including those in the name of team PO
  • project manager, including those in the name of SM
  • technical leader or architect
  • team leader, in addition to SM and manager
  • etc.

What these special roles are doing largely belongs to the scope of self-organizing teams. The most helpful way to proceed is for them to join feature teams, as team members. In fact, this is what is going to happen in LeSS adoptions - simplify the organization to scale up.

Are we going to further reduce special roles after adopting LeSS? In LeSS organizations, self-organizing teams are the basic building block, while special roles are mainly in two kinds.

  1. PO for product vision and direction. If we consider shared vision, it is possible that vision is co-created by teams and product community. See more in Shared vision on product.
  2. SM and manager for team and organizational capability improvement, as coaches and facilitators. Even with team maturing, it is very likely that they still benefit from having some coaches and facilitators around every now and then, if not all the time.

Therefore, the goal is to have low - perhaps not zero - %(people in special roles) outside teams, and have high degree of self-organization in teams.