Introducing the Chief Product Owner as a Key Element to Scaling Scrum

The Chief Product Owner is one of the roles recognized by Scrum@Scale. The role is similar to the role of the Product Owner but driven at the Scrum of Scrum Level. This allows the Product Owner role to remain intact, including having decision making power over their portion of the product. The two roles are also expected to work together on an ongoing basis to fulfill their combined responsibilities. This is a healthier alternative to adding a Proxy PO to scale operations. Here, we list the responsibilities for the two roles and why this is a preferred alternative to Scale.


The Product Owner (PO) has eight primary responsibilities. The role may enlist help to fulfill responsibilities as long as the person remains ultimately accountable.


Responsibilities of the Product Owner

1. To own the “What” and “Why” of the product building process.

2. To be a representative of the customer for the Scrum Team.

3. To decide what to release to the customer and when to release it.

4. To maximize the value of the product increments.

5. To own and be accountable for a ready Product Backlog.

6. To define scope for the Development Team by using Product Backlog items’ prioritization.

7. To establish and promote the product vision.

8. To decide on the product investments and to improve returns - maximize the ROI.

The Chief Product Owner (CPO) also has eight primary responsibilities. The role works with the network of Product Owners on a daily basis to assist with impediment removal, product backlog refinement, and release planning. This arms the PO with the information and assistance to make daily decisions that are critical for product success.


Responsibilities of the Chief Product Owner

1. Has the same responsibilities of the PO but at scale.

2. Sets a strategic vision for the whole Scrum of Scrum.

3. Creates a single, prioritized backlog for the Product Owner(s) to decompose.

4. Performs release planning for the Scrum of Scrum.

5. Consolidates a minimal and uniform “Definition of Done” that applies to all teams.

6. Resolves dependencies and impediments raised by the teams.

7. Establishes and monitors effectiveness metrics.

8. Leads the MetaScrum event if there is no CCPO to linearly scale the role.

Antipatterns to Avoid


There are three main scenarios where an organization might consider adapting a Proxy PO structure. Let us examine each to consider alternatives that avoid these antipatterns:


1- One Large Product with a Single PO – I’m often asked, “What about the case where we have a very large product and multiple teams where a single Product Owner cannot handle all the work involved?” This is where a network of Product Owners comes in handy. A Proxy PO implies that the person is just holding down the fort for the real PO. Instead, consider making the “would-be” Proxy PO a real team PO and then adding a Chief PO into the mix to work with multiple Team POs. A Chief PO can then work with the local POs to fulfill the responsibilities of the role. One might think, “Isn’t that splitting hairs, isn’t a Proxy PO the same as a Team PO and you just renamed the PO to a Chief Product Owner?” Not at all. The main difference is that the team POs still have autonomy and decision-making ability. They simply work with one another to coordinate the work relating to their joined backlog. This allows for the work to flow without stopping and for the individual scrum teams to make decisions in a shorter time.

2- One PO handling Multiple Products - I often find that a Proxy PO is used when the organization has multiple products and the PO is overwhelmed but the organization does not trust others to take over the role. In this scenario, the organization opts to place a body on the ground who defers all decision making to the real PO who is too busy handling other issues. This stunts the flow of work and frustrates the development team since they now must wait for the information to flow through different people before anything can be done. This can be avoided by establishing empowered PO roles to work with the respective development team and adding a CPO to prioritize the aggregated work.

3- A PO in a different time zone - Nothing slows the decision-making time like time zone differences. Having a PO in a different part of the world than where the teams are located can slow down the start of the process by as much as twelve hours. In this case, it is best to adopt a Chief PO to Team PO structure where the team PO is as close as possible to the development team time zone. Remember that it is critical for the team PO to have decision making power. This means that the person needs to understand the requirements and priorities well. To do this, the Chief PO meets with the team POs daily not to hold a status meeting but to coordinate the priorities and dependencies throughout the network of teams.

A decisive PO who can provide answers to the team quickly is a key element of success in Scrum. In fact, teams that can make decisions quicker have a 25% higher chance of success over those that take longer. Therefore, an empowered Product Owner who is always available to the team is a critical success factor. If your product owner is overwhelmed and it’s time to scale the role, consider introducing a Chief Product Owner as a healthier alternative so your organization can continue to scale toward greater Agility.

SaS-Logo_square.jpg
ScrumMaster-Badge.png

Connect Now

© 2020 By Agile Genesis