What role can scrum master have/take when product owners have different opinions?

Question

Here's a specific example that our two product owners are working out right now:

PO-1 wants to be more 'purist', saying "this is how the UI should be done", while PO-2 says "we have to keep moving on, so let's take a shortcut here".

This came up in sprint review when looking at a user story just completed. Implementation differed from the story on one point, and it turned out that during the sprint a dev talked to PO-2 who decided on the shortcut.

Let's stick to this example, otherwise the question becomes too broad.

Answer 1

The Scrum Master will take the role of a facilitator to help the two POs reach an agreement.

The Scrum Guide says:

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

This also applies to how backlog items should be delivered. Differences in scope will be negotiated by convincing the PO.

If you have more than one PO, it will cause conflicts and confusion within the dev team. The situation ends up like those TikTok clips where two owners of a dog run in different directions at the same time to see who the dog will follow. In most of the clips the dog just stays on the spot wondering what the heck is going on.

You want a Scrum team to have flow, not be left wondering what to do when the two POs disagree or want different things.

So in this case you are lacking one item from your working agreements: Who has the final decision-making power when there is conflict in priorities or approach?

This needs to be agreed within the entire team and will probably suck for one of the POs (ahem... ego), but it will protect the team and you will follow the Scrum Guide better because PO2 will then have to convince PO1 instead of taking the conflict to the entire team.

Answer 2

In Scrum, each product has a single Product Owner accountable for managing the Product Backlog and maximizing the value of the work done by the Scrum Teams working on that product.

Something that I think Scrum doesn't represent well is the complexity of product management. As a discipline, product management encompasses customer research, market research, competitor analysis, product strategy, creation and maintenance of product roadmaps, stakeholder engagement, requirements engineering, and more. It could be hard to find a single person who has the skills to do all of these well, and even if you could, their time would be short. These skills aren't associated with a Developer on a Scrum Team, as they aren't about creating the next product Increment, and there's no other group on a Scrum Team. The idea that there likely is (and should be) a product management team is missed.

However, even if you do have a product management team, having a single product decision-maker is something that I'd consider a good practice. When you have conflicting ideas, someone needs to deconflict those ideas and make the final decision. This is why Scrum has a single Product Owner, rather than a team of equals or a committee.

In this specific problem, though, the Developers are also missing. The Developers are the ones accountable for the quality of the product. Are the Developers involved in scoping the size or level of effort of the work? Is doing it the way it should be costing too much time and effort for the value of the work? Conversations about the pros and cons of different approaches, especially as they impact product quality, can't happen without the Developers.

Answer 3

TL;DR

You have both a process problem and a communications problem. I address both below, but you can actually leverage the Scrum framework to resolve both problems by focusing on the communications aspect first.

Long term, you will want to address the process problems, but even in the short term you can improve the outcome of your current Sprint with better communications and transparency. I explain how to do that in the sections below.

First, Address the Elephant in the Room

PO-1 wants to be more 'purist' this is how the UI should be done, PO-2 says we have to keep moving on so let's take a shortcut here.

Scrum has one, and only one, Product Owner per Product Backlog. If you've got multiple Product Owners, whatever they're doing isn't Scrum. It could be SAFe or something else, but it's definitely not Scrum. The 2020 Scrum Guide explicitly says (bold emph. mine):

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner. (Schwaber & Sutherland, 2020)

If it's some form of scaled agility, then there should either be a role or event for them to hammer out their differences so the team has exactly one Product Backlog to work from. Otherwise, as Scrum Master you should advise them to pick one person to be the canonical Product Owner for the team, and all other Product Owners or stakeholders should funnel their priorities through that singular person.

Second, Address the Practical Constraints

In Sprint Planning, regardless of how the Product Backlog is really ordered and regardless of whether your multi-PO process is really working for the Scrum Team, there is still a need plan the work taking the current Sprint Goal into account.

Pragmatically, that means that if your current Sprint Goal is to "Embiggen the Widget" then the Developers must consider which version of the user story:

1. Is best aligned with the current Sprint Goal.
2. Fits within a single Sprint.
3. Doesn't push other user stories necessary for the current Sprint Goal out of the current Sprint.

My educated guess is that the "shortcut" version is more likely to be aligned with meeting the current goal in a single Sprint, albeit at the potential cost of some tech debt that must be addressed in a future Sprint. In iterative methodologies you are always aiming for "good enough for now," not perfection!

However, it's certainly possible that one big honkin' user story that consumes the entire capacity for the Sprint can or should form the team's singular goal for the Sprint once fully decomposed for the Sprint Backlog. If that's the case, you can offer the whole Scrum Team a choice:

1. Meet the current goal with the "good enough" solution.
2. Change the Sprint Goal, spend time decomposing the "ideal" solution to ensure it fits onto the Sprint Backlog, and then build your plan around that commitment even if it means postponing other work.

Ultimately, the Sprint Planning event is just another inspect-and-adapt opportunity where trade-offs are made transparent and consequences to the project are made visible to all stakeholders. Within the Scrum framework, the constraints of scope, schedule, budget, and quality still apply, and while scope should generally be the flexible constraint in Scrum it's possible to make other choices so long as they don't violate the basic rules of the game everyone agreed to when they chose Scrum as the project framework.

Advantages of the "Goal/Resources/Capacity Fit" Approach

The nice thing about this approach is that it takes ego out of it. It's not about whose user story is "better" or "more correct." It's simply a question of which one is more closely aligned with the near term product roadmap and the resource constraints available from the Developers for the current Sprint.

The Scrum Guide explains this process as follows:

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

With this in mind, it doesn't really matter what the Product Owner(s) eventually decide to prioritize. Within the Scrum framework, it's solely up to the Developers to determine what Product Backlog items to select for the current Sprint Backlog based on the agreed-upon Sprint Goal, the Developers' reasonable confidence that those items can be completed per the Definition of Done by the end of the Sprint, and what Increment(s) the Developers are prepared to commit to in order to meet the current Sprint Goal.

The Sprint Backlog as a Knapsack

It also helps to think of the Sprint Planning event as an active collaboration between Scrum roles with aspects of the knapsack problem thrown in for good measure. You can pack a Sprint Plan's knapsack in many ways, but a knapsack has finite capacity and should only be packed with things that relate to the destination one is packing for. No one can force the Developers to commit to more than one Product Goal or Sprint Goal at a time—that's disallowed by the Scrum framework—or to stuff more things into the knapsack than will actually fit. This encourages collaboration and communication, which is something that a cursory reading of the Scrum Guide often overlooks.

While certain roles are responsible for a Scrum artifact or process, the roles must cooperate with one another in order for the process to function effectively. Communication is what enables that. Many Scrum implementations fail when people miss that essential truth, and treat Product Backlog prioritization, Sprint Backlog selection, or other aspects of the framework as fiat decisions rather than pragmatic horse-trading. Be pragmatic within the framework's rules and the whole Scrum Team and its project are much more likely to succeed.

Answer 4

Ideally there will only be one Product Owner, but in your situation I would recommend:

• Let the two Product Owners decide among themselves which product approach to take.
• Give them advice where you can, but make it clear that product decisions are theirs to make.
• Keep the stakeholders informed of the decisions being made by the two Product Owners.
• Take note if the disagreements between the Product Owners slows progress. If this happens then raise it at the retrospective or include it in your reporting (e.g. "The planning meetings are a little slow as we work through some disagreements between the two Product Owners.")

If having two Product Owners results in a noticable team performance impact then you might also want to coach the organisation on the benefits of having a single Product Owner as defined in the Scrum Guide.

Answer 5

The Scrum Master should make sure there is alignment between the two Prod Owners. This could look like:

• Facilitate a conversation with relevant stakeholders about the item.
• Ensure discussion & negotiation covers scope & priority.
• Have the owner of the item make a decision & socialize that to stakeholders so they can plan accordingly.

If there are really 2 owners of the item then they have to negotiate/reach an understanding & socialize it so others can plan.

Answer 6

From the Scrum Guide:

"The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner."

And:

"The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable."

Agile coach required but in a nutshell, too many cooks spoil the broth