Area Product Owner

An Area Product Owner (APO) specializes in a customer-centric area and acts as Product Owner in relation to the teams for that area (see Figure 1). An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.

Product Owner Team

Product Owner Team—The APOs and the PO together form a team—the Product Owner Team. This team makes product-wide prioritization decisions, but the PO always has the final decision. Also, scope and schedule decisions stay with the PO—he decides when to release what.

Teams are distributed over the requirement areas based on the PB priority. Areas are of different size in terms of effort and so they contain a different number of teams. Too-small areas are not a good idea because they result in many backlogs and many APOs. The overview is lost and teams develop low-value features. Rather, prefer a couple of small areas combined in one broader area—increasing the flexibility within this area. On the other hand, too-large areas are difficult for one APO. To strike a balance, consider a minimum of four and a maximum of ten teams per area

Why Areas and Area Product Owners?

The main reason for having Area Product Owners is to prevent the Product Owner from becoming overloaded. Without an Area Product Owner, the Product Owner overload would be because:

• the refined part top of the PB (for the next Sprints) is becoming too large
  Lean thinking promotes small batches and short cycles. We suggest that each team have at least four PBIs for each iteration that they can complete independently within that iteration. With 50 teams this leads to a PB with 200 PBIs just for one iteration. Prioritizing 200 PBIs per iteration is too much work for one PO.
• teams working on the whole system
  Teams working on the whole system—Feature teams are good, and so is learning new parts of the system. But too much learning without delivering value is not. This can happen when teams work on completely unfamiliar features. They have no opportunity to specialize and this affects teams’ velocity. How to strike a balance?
• the PO dealing with too many teams
  With all the tasks the PO needs to do, it seems impossible for her to work with more than a couple of teams. How to solve this? One way is for teams to take over the clarification of Product Backlog Item (PBI) work by including subject matter experts on the team. An alternative is for someone to assist the PO with clarification work. He joins the Product Owner Team but does not make decisions related to prioritization. Using these techniques, one PO can work with up to five or ten teams. More than that will cause information overload for the PO and makes iteration planning difficult.