June 2021 Archives

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.

About this Archive

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

March 2021 is the previous archive.

July 2021 is the next archive.

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