The Odd-e Blog

The Authors

"Component Product Manager"

During the past half year, I have seen the similar situation at least three times in various organizations. This probably means that it is worth an elaboration.

"Component Product Manager"

We know of component team, but what on earth is "component PM (Product Manager)"? Doesn't it sound absurd? I did not really hear the exact term being used, while it came out from the people whom we together ponder over the situation - "we have not only component team, but also component PM"!

We were discussing about how to transition from separate backlogs to one shared backlog. As shown in the below diagram, they currently have respective PMs and development teams responsible for certain areas (A/B/C) within the product. In order to move towards one backlog, besides the teams, the PMs also need to change.

component product manager - 1.jpg

This term contains two parts - Component and Product Manager, and let's understand them separately.

  • Component
    • The component responsible by PM is to some extent customer oriented, as a customer or business area inside the whole product.
    • It may depend on other areas to together create value, but it is occasionally valuable on its own, as illustrated in the shared backlog on the right side of the above diagram.
  • Product Manager
    • Its alternative name is Product Owner, but they are actually more like BAs (Business Analysts). In some organizations, they are also called so.
    • They specialize in certain area. As they are coupled with teams, the corresponding teams specialize in the same area.

In short, "Component PMs" are the BAs specialized in dependent areas.


When we have all teams share one backlog, the generic teams (1/2/3) who work on whatever features with highest value simply can't continue to couple with the specialized BAs. Therefore, these BAs need to decouple with the teams and somehow connect to the one backlog, as shown in the below diagram.

component product manager - 2.jpg

It is common that the same technical stack is used across those areas, thus, the teams usually feel comfortable in expanding their scope to develop features from end to end. So, this time, the limit is more on the specialized BAs. They see it a big challenge to learn and analyze broadly across the whole product, for whatever features with highest value in the one backlog. You may argue that developers can learn broadly, why can't BAs do the same? It is of little avail if you encounter a view that developers only need to code for specification, while it is much more difficult for BAs to learn broadly, thus they have to specialize in some area. So, the better strategy is to focus on the system optimizing goal, which is to discover and deliver the most value as the whole organization.

What further complicates the change is that specialized BAs are often located in the product department, rather than the development department. As BA is a part of feature team, the necessary organizational redesign (aka organizational flip) for feature teams is bound to span both product and development departments.

Change Paths

According to the LeSS framework, it is actually one-step change to create both one product backlog and feature teams.

  • (one product backlog) All teams follow one priority, not constraint by current skills. When work and skill do not match, it triggers learning.
  • (feature teams) Each team includes dedicated BA, and BA will cross-learn in the same way as other members do. All team members have the same reporting line.

It is possible to have more gradual steps, i.e. gradually break down BA's specialization on areas and change the organizational structure as well.

  1. (one product backlog) BAs are still specialized in areas, then, they are de-coupled from teams. However, BAs follow the same priority from one backlog, and are not allowed to analyze features in lower priority just in order to keep busy. (hint: observe what they will do then)
  2. (one product backlog) BAs break down the specialization on areas, as shown in the below diagram. They learn broadly to be able to work according to one priority.

component product manager - 3.jpg

  1. (feature teams) BAs join feature teams, and any BA belongs to one team stably.
  2. (feature teams) BAs and developers align performance measures across product and development departments, so as to break down functional silo and really have common goal.
  3. (feature teams) Reporting structure is changed so that all feature team members have the same reporting line, as shown in the below diagram. This further promotes cross-learning within the teams.

component product manager - 4.jpg

Eventually, we evolve into the LeSS structure - multiple feature teams share one product backlog.


Domain Teams and Product Definition

A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those domains, such as adding a payment method, managing shared order, tracking shipping status, etc.

What change do we bring onto these teams in LeSS adoption? There are two essential elements in LeSS organizational design - feature team and one product backlog. How does this domain team structure differ from LeSS structure?

One Product Backlog or Feature Team?

At first glance, these domain teams seem like feature teams, as they are customer oriented to some extent. Then, the change would be towards one product backlog. Instead of each team focusing on one domain (team A/B/C for domain A/B/C respectively), all teams will work on whatever features at the top of the backlog.

Let's look at a product backlog as below - all items belong to only one domain. A/B/C in the backlog indicates the domain each item belongs to.

domain teams and product definition - 1.jpg

In this case, the domain teams are indeed feature teams, while the main change would be to share one product backlog for maximizing the value delivery globally, i.e. among all domains. In order to share one product backlog, the teams need to transition from single-domain to multi-domain.

Furthermore, let's look into customer value. Does value come from one domain or across multiple domains? How much percentage from one domain, and across domain? Let's look at another product backlog as below - many items are cross-domain.

domain teams and product definition - 2.jpg

In this case, the (single-)domain teams are essentially component teams. If we keep them intact, teams can't deliver many items from end to end. Therefore, the first change would be to create cross-domain feature teams 1/2/3. Team 1/2/3 can be fully cross-domain, each team covering A+B+C; or partially cross-domain, e.g. covering A+B/B+C/A+B+C by team 1/2/3 respectively.

Often, we don't introduce another dimension of specialization for these feature teams any more. Instead, we let them share one product backlog. However, if necessary, we can still take smaller step in first creating cross-domain feature team specializing in some customer dimension.

In either case of the above backlogs, we will create multi-domain teams, but for different reasons. When values come from single domains, those (single-)domain teams are feature teams, multi-domain teams are created to globally maximize value delivery (further refer to Number of backlogs and multi-learning: 4) specialized feature team). When values come across domains, those (single-)domain teams are component teams, multi-domain teams are created to first speed up end-to-end delivery (further refer to Number of backlogs and multi-learning: 2) functional team and component team).

Product Definition

The deeper meaning of feature team connects to the product definition. "The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product." (further refer to Is team in Scrum feature team?) So, when single domains are defined as products, those (single-)domain teams are feature teams. When multiple domains all together are defined as a product, those (single-)domain teams are not feature teams anymore; the feature teams in the new context need to be cross-domain teams.

This change relates more to the LeSS guide "feature team adoption map" as below.

domain teams and product definition - 3.jpg

In fact, Y-axis shows the gradual expansion of product definition. The scope of feature team gets broader - from single-domain to multi-domain - when the product definition gets broader. In fact, by creating one product backlog to include multiple domains, we implicitly expand the product definition.

In the LeSS guide "define your product", one of the questions that expands product definition is "our product is part of? what problem does the product solve for end-customers?". Let's apply this question in the example of e-commerce. Initially, we may treat OMS as a product, and OMS team is a feature team. Then, as OMS product is part of the e-commerce solution, we expand our product definition to e-commerce. OMS becomes a component in the expanded product, thus OMS team becomes a component team. To make it a feature team, we expand its scope to e-commerce.

In the same guide, there are also questions that restrain the product definition as practical. One of them is "what is the product vision? who are the customers? what is the product's customer domain?". Applying this question here, it is also possible that the company decides to focus on developing an OMS or payment system rather than the whole e-commerce solution, then, OMS or payment system becomes the product. Accordingly, OMS or payment teams become feature teams.

In conclusion, the change on the domain team structure is closely connected to product definition. A feature team often becomes a component team when product definition expands, while product definition may be implicitly expanded when creating one product backlog. In fact, the fundamental change is the expansion of product definition!


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.