Why you Need Only ONE Product Owner

Hello Roland,

Firstly, great post! The point that you made about many PO's bringing in unclear responsibility and ownership, from my experience working with a team, having many PO’s also meant that they were all not on the same page sometimes. This, in turn, would make it hard for team members to understand the requirements properly. This would also mean that delays were faced as requirements kept changing as product owners didn’t have a mutual understanding. Lastly, as you said, it is important to have only one product owner so as to promote transparency. I agree with that last point as having one product owner will create room for less confusion and more collaboration. Transparency will also improve the relationship between the PO and team members.

Thanks, and Regards,
Kunal Shah

Hello Roland,

This point adresses a topic which I would recognize as contradictionary points in the SCRUM guide.
About the development team, the SCRUM Guide says the following:
- "Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole"
- "..empowered by the organization to organize and manage their own work"

However, if the PO has the development team do the work he is accountable for, the above "rules" are broken.

In addition, "replacing" the product owner (in other words, fire him and hire someone else) is an advice that probably does not help in most situations.

In my opinion, a product that consists of too many modules that are developed by several development teams should be revised in terms of the product architecture. In such cases most probably the functionality is separated as the user groups are (e.g. each module for a different department with different purpose and different persons using it). In most cases it is better to cut the "one product fits all" into multiple products that can be planned and developed as independent from each other as possible. In that case, multiple product backlogs could co-exist, each with its own prioritization that matches for example the needs of one business department, and a product owner that maintains knowledge about the details of the meeds of the department, to be able to provide a proper prioritization for them.

Good afternoon Roland,
I really enjoyed reading your blog. It was nice to read things to do when a PO is in fail state. I had an opportunity to work on an Agile project where we had to remove the PO. For whatever reason he was having issues with two other team members. Something about how they did their work. He was removed and another replaced him. The new PO actually motivated the team so that we performed at a higher rate in producing deliverable's.
How we attempted to work with the old PO: we as a team started to take on more of the responsibility, which at the time seemed right for the situation. We even modified the stories and even reduced the stories in the sprint in-order for him to understand how we estimated timing and velocity.
Again, thank you for the blog post.

Hi Roland,

I am confused as to how a product owner will conduct events (sprint planning, sprint review) for multiple teams. Assuming a 2 week sprint with around 4 hrs for planning, how will a PO conduct this event for multiple teams?

Thanks,

Rehan

Hi Roland,

Is it however possible to split a product into smaller sub products and thus reduce the simplicity. Will there not be a human limit to how many scrum teams you can manage ?

Hi Rehan, if we are talking about a single Product with a single Product Owner, would it be necessary for individual Scrum teams to have separate Sprint Reviews? In my experience, shared Sprint Reviews are a great way to consolidate the time required for busy stakeholders and POs alike...not to mention focusing on the Product Increment (outcomes...not outputs) that the Scrum Teams supporting the Product are producing. With 2 teams...a shared Sprint Planning might also be useful to ensure the teams are synched up on dependencies...with 3 teams and above, consider Nexus to help the teams collaborate and coordinate their work.

Hi Einer,

We need to appreciate the difference between the two words, "Responsibility" and "Accountability". If the PO has the Development team members do the work he is accountable for, he merely is delegating the "responsibility", and still retaining his "accountability". In other words, accountability of the PO is not diminished in any way by the way to delegation. Hence in the scrum guide it is clearly written " The PO may do the above work or have the Development Team do it. However, the PO remains accountable".

In that vein, Roland's point really resonates with my thinking that the PO should not do the all the refinement/ providing all the details. Actually, it is the development team with enough domain knowledge (which Roland is advocating) that have all the wherewithals to refine the sprint backlog throughout the sprint. Roland, in his conclusion, I believe, also alluded the necessity of the same in cases of large scaled programs.

Hi Roland
I was clearly pointing out that the scrum guide says, the development team is accountable for their work. If you say, PO is accountable for work done by development team, then this is contradictionary and the idea of empowerment behind it is broken. At the end, development team is waiting for orders, or doing nothing if no orders are given by PO. Seen many times.

You raise some valid concerns about scaling the Product Owner role and I agree that there must always be 1 person responsible for the whole product, with 1 overarching Product Backlog.
However, when we have more than a few teams, I believe scaling the Product Owner role does become necessary. I don't see a single PO serve 200 teams working on 1 product (is this really what you are suggesting?). Various scaling solutions/frameworks have different solutions for this, typically by scaling the PO role and adding a layer around 8 (LeSS) or 9 (S@S) teams. In these setups, there is still 1 (Chief) PO, and multiple ("normal") PO's, each serving 8 or so teams.
A scaled setup is more complex than a single team, and, as well stated in the article, requires that teams are aligned (with overall priorities set by the CPO) and practice systems thinking, reduce their dependencies on each other (with feature teams rather than component teams). Teams will become specialized in certain areas but will be able to work on other stuff as well (I often compare this with T-shapedness within a team, this time between teams). In my experience, the problems you describe are typical results of doing this wrong.

If you scale Scrum using Nexus, the Nexus Sprint Review replaces ALL scrum teams sprint reviews, as it is the integrated increment that is being reviewed and not each teams individual increments.

Cross-team refinement becomes an event in Nexus, stressing the importance of backlog refinement. Appropriate members of each scrum team participate in the refinement and planning events.

Appropriate members of the scrum teams participate in the Nexus Daily Scrum, so they can take back any cross-team dependency & integration issues to their teams to be discussed and then planned during their own Daily Scrums.
The PO becomes part of the Nexus Integration Team, and can delegate responsibilities to scrum team members if required, as long as agreed upon guidelines are met that the PO lays out, because after all, the PO is still accountable for those responsibilities, just like in Scrum, this is because Nexus is still Scrum.

I believe that if you split a product into smaller products, then each of those products are classed as separate products, meaning they have their own backlog and PO. If I am wrong, please let me know.

From the Scrum Guide:

The Developers are always accountable for:
● Creating a plan for the Sprint, the Sprint Backlog;
● Instilling quality by adhering to a Definition of Done;
● Adapting their plan each day toward the Sprint Goal; and,
● Holding each other accountable as professionals.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is also accountable for effective Product Backlog management, which includes:
● Developing and explicitly communicating the Product Goal;
● Creating and clearly communicating Product Backlog items;
● Ordering Product Backlog items; and,
● Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

LeSS uses the setup I suggested (scaling the PO role through what they call PO and Area PO). So I guess we agree, though the article seems to state to always have only 1 PO, and this role (or accountabilities) is not scaled.

Well put and thanks, @Roland - will be useful for inhouse arguments. Interesting to find and read this article in 2024 after being on LeSS journey for some time :-)