More than one Product Owner on a project?
Ideally, in an agile project, a Product Owner manages the requirements and communicates with all stakeholders. In most cases, one person is sufficient to fill this role, and it is even preferable to have a single person to focus on requirements sourcing and backlog management, but there are cases where several people are assigned to this role on a project, or where several scaled projects need to work together.
We will now deal with the former case, showing what to look out for in a non-scaled project where several PO working.
First let's look at the theory, what the Scrum Guide tells us:
"Several Scrum teams often work on the same product. A product backlog describes the work to be done for the product being developed." - says the Scrum Guide
Let's look further at the recommendations:
"The Product Owner is a person, not a committee." - Scrum Guide
An Product Backlog = One Product Owner, the Scrum Guide is explicitly not permissive in this respect, so the question arises, why are we writing an article on a topic that does not exist in theory?
However, practice shows otherwise, in agile operations implemented by companies, it can happen on projects when multiple designers are assigned as Product Owners, as we have seen examples that work surprisingly well and terribly badly, we will share with you what patterns to follow.
1. Separate responsibilities at Product Owner level
It is a big help when Product Owners are not responsible for the same area, so there is less room for disagreement between them. When two people are responsible for the same area, in fact two are not responsible for it because of shared responsibility. Such areas can be:
- Responsible for business
- Responsible for legal compliance
- Technical person
- Backlog responsible
- UI / UX responsible
- Test data responsible
2. Additional role: Business Analyst
It can work particularly well in a business analyst in teams where several Product Owners are involved in the life of the team. In such cases, the extent to which Product Owners should be involved in the life of the team should be decided on a team-by-team basis.
In general, it is worth using the business analyst as a Proxy PO to hide the uncertainty from the development team, but it is worth having the whole team present at the backlog preparation meetings.
3. Preparatory Jour-fixe, the battle of the big boys
Just as when mum and dad fight at home as children, disagreements in front of the development team are damaging, we can agree. That's why it's worth having a pre-screening session with Prouct Owners, Business Analysts and scrum master so that the decision-makers are already in agreement.
In particular, because of the short time available, it is worthwhile to use some kind of methodology for the issues that arise, use colour coding, categories, identify the people responsible who need to prepare so that you don't have to organise a frequent follow-up meeting.
4. If it doesn't work well, root-cause analysis is performed
Ultimately, it is always important to analyse the situation, what is causing the problem. When doing a root-cause analysis, try to get to the root of the problem, there are some very good techniques to identify which problem should be solved first. For a simple example, we can use the problem donut.
Obviously, our article assumes that we are already in a situation where several Product Owners are working on the project. The best way to avoid this situation is to work with one PO.
But if you're in a less than ideal situation, try to make the best of it.
"If you change the way the team works, don't change several things at once, so that you can measure the impact." - This is our advice
If you come across a good sample on this topic, please let us know how the team works and what you think are your strengths that have allowed you to build a well-functioning team with several Product Owners.