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

About this Entry

This page contains a single entry by Lv Yi published on June 30, 2021 9:04 AM.

Follow value in defining RAs was the previous entry in this blog.

Limits to one Product Backlog - 2 is the next entry in this blog.

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