Scrum prescribes one person in the role of Product Owner (PO). Not multiple people, not a committee, just one person:
“The Product Owner is one person, not a committee.” (Scrum Guide)
And when multiple teams work on a single product, the Scrum Guide says:
“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” (Scrum Guide)
I encounter many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak “to make Scrum work in your context”.
The apparent need for multiple POs
When companies need to scale up their development effort, they tend to copy complete Scrum Teams, including the Product Owner. They soon find out that the PO role does not scale that well by multiplication. As they lose transparency over responsibilities, they try differentiating the PO role in various types of POs such as Feature Owners, Epic Owners, Component Owners and more. They are looking in the right direction to solve their problem but choose the path of complexity instead of simplification: When working with multiple teams on one product, you only need exactly one Product Owner. A product is a real product that satisfies a customer need and people want to pay money for it.
In many cases, I see that there is not a problem in handing over accountability for the whole product to one single person. However, people resist having a single PO because they consider the concept to be unrealistic. They feel having multiple POs and multiple product backlogs is a necessity for various reasons:
- The Scrum Guide says we need a PO per Scrum Team, which means we must have multiple POs as we have multiple teams. However, this is a myth; One Product means one Product Backlog and one Product Owner.
- The domain knowledge for a complex product like ours is too vast for one person to grasp.
- The workload to produce all user stories is too big and cannot be handled by one person.
- There are too many meetings in Scrum for a single PO to attend.
- With multiple POs the PO-availability for teams can be provided at the required level.
- It is easier to have many POs as it avoids the fight over who should become the one real PO.
- We come from a situation where we thought we needed one PO per team. Now that they are working here, we cannot just send them away.
- This is space to fill in some silly argument you have heard in your organization.
Downsides of having multiple POs
Having many POs encourages micromanagement of teams. In a Product Owner per team situation, the PO becomes the person that spells out all the detailed specs (user stories). This setup leads to teams focusing on story readiness, negotiating the level of story detail instead of focusing on value creation. This is a well-known pattern known as the “contract negotiation game”. Another effect is the growing absence of domain expertise in the teams. Domain knowledge is concentrated in the PO, which makes the team stick to executing tasks (as opposed to solving customer problem), which re-enforces the need for more PO’s. The PO per team setup reduces opportunities for learning and self-management. I normally suggest making the PO’s part of the development teams they work with. They will get the opportunity to become a multi-skilled developer with a focus on analysis.
Many POs requires coordination and alignment. The PO’s collaborate in a PO team to agree who takes care of which items on the Product Backlog. The customer features are sliced and each PO gets their own sub-scope of the customer value in a Product Backlog. The work is sliced on arbitrary and artificial grounds, creating a coordination need to deliver an integrated product by the end of the sprint. Also, prioritization is decentralized and will lead to local optimization per backlog. This inevitably introduces asynchronous dependencies between teams, as some teams are “full” and cannot do certain work other Teams depend upon. Teams don’t have a whole product view and loose track of what is customer value. If the coordination need is high between PO’s, then probably the Product Backlog has not been sliced to optimize for minimal dependencies and the teams are not structured to serve that goal. Having only one PO managing a single Product Backlog for multiple teams creates the transparency required for proper empiricism.
Many POs bring unclear responsibility and ownership. One PO means that one person is accountable for the ROI on the product under development. With multiple Product Owners, accountability, responsibility and ownership are oblique. Management has a tough job in getting a grip on Product development. Multiple PO’s stimulates part-time jobs, by adding the PO-work to someone’s existing workload. This introduces a conflict of interest. With multiple people working part-time on one product the situation does not get any better. Volunteers come to the rescue, thinking “if nobody takes care of this, I will” and change backlog item priority, add items or even create their own backlog, creating more complexity. In such cases, I suggest restoring transparency by merging the additional backlogs into one single Product Backlog.
What if it fails?
If your PO cannot handle the work involved managing the product:
- Being a PO is a difficult job and not everybody can do it. Hire someone else, or maybe you can fix it by sending the PO to proper training.
- Reduce the number of features (user stories) in the backlog, they PBI's are probably too detailed. Aggregate specs to a very low number (3 to 5 stories per team per sprint) to experiment with.
- Stimulate “prioritization over clarification”. Reduce the level of detail at which the PO is dealing with features by explicitly bringing the clarification responsibility in the team. The PO can help by connecting the team to a stakeholder or customer.
- Limit the planning horizon to no more than 2 to 3 sprints of work ahead, as preparing more work is likely to result in waste. If you are able to predictably specify your work more than 3 sprints ahead you maybe should not be doing Scrum as your product is not complex enough.
- Prevent the Product Backlog from spawning by extending the DoD (this increases the end to end capability of the Scrum team and possibly simplifies the Product Backlog), continuously reducing technical debt with merciless refactoring and strict bug policies.
Conclusion
The PO role is better not scaled by multiplying POs as this has many downsides. I encourage to have a single Product Backlog and a single PO being responsible for return on investment when developing one product. Having a single Product Owner creates transparency and enables empiricism. The concept of a single Product Owner in a scaled environment (multiple teams working on a single product) is challenging if you stick to the idea that the PO has to manage every detail. When scaling, try shifting the PO focus from clarification to prioritization. This will encourage the teams to better understand what needs to be created for the product. This approach is completely in line with backlog management described in the Scrum Guide:
“The Product Owner may do the above work (Backlog management) or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.” (Scrum Guide)