Should a Scrum Master Become a Product Owner?

Short answer: no. But let me explain why.

Scrum Guide

There isn’t anything in the scrum guide that prohibits this. But it’s probably not very wise.

Scrum Accountabilities

In Scrum, there are three accountabilities:

1. Developers → the people doing the work, delivering a high-quality done increment.

2. Product Owner → maximizing value.

3. Scrum Master → looking after the effectiveness of the scrum team.

So what’s the problem?

When the Scrum Master who’s looking after the effectiveness of the scrum team starts to wear the hat of maximizing value, conflict ensues.

This could lead to a situation where the developers and the team deem it that the person who is now a Scrum master product owner combined, has a lot of power and needs to be followed.

There might be less inclination from the developers to have healthy conflict because the person who is the Scrum master and product owner has a lot of power.

It’s something I advise against, but it is possible. In the same way, you can actually have a Scrum team of one person if you want to.

But is that really a team?

It’s Scrum Master, Product Owner, and Developer in one person.

Sometimes I say the best team is one person because you’ve got fewer communication channels and you can just do everything yourself.

I’m being ridiculous because we all know that you usually have more than one person in a team, and you’ve got people working together towards a common objective to try and avail some opportunity or to solve some kind of problem, together with the customers.

So I don’t advise it.

Let’s go through all possible combinations

Technically, you are allowed to be scrum master and product owner. You are allowed to be a Developer and Scrum Master. You’re allowed to be a Developer and Product Owner. You could be a Developer and Scrum Master, and Product Owner.

But how effective can you be?

Exploring the Scrum Master Role

There’s a lot of work in Scrum Master.

Michael James has a lovely expression:

A good Scrum Master can look after three teams. A great Scrum Master can look after one.

There’s a lot of things that a Scrum Master is expected to do, but it’s misunderstood.

A lot of people misunderstand that the scrum master is like a jockey, they’re doing reporting and booking meeting rooms, essentially acting like a coordinator, almost like an agile project manager.

There is no agile project manager in Scrum, and so a lot of people expect the Scrum Master to be doing these things. These are misunderstood stances of the Scrum Master.

What the Scrum Master should be doing is:

1. observing through listening, sensing, smelling, whatever senses they’ve got available;
2. mentoring, giving advice, coaching, maybe asking Socratic questions teaching, coaching, mentoring, with permission. Don’t inflict help on people;
3. acting as a change agent;
4. keeping an eye on the scrum implementation;
5. working with the rest of the organization to help them to understand how scrum and agility works; and
6. removing impediments that are beyond the control and influence of the team.

That’s a full-time job.

Exploring the Product Owner Role

I’m okay with the Product Owner refining Product Backlog items but not writing them.

The Product Owner does not clarify requirements. The Product Owner clarifies problems to be solved and maybe opportunities that we want to avail of.

The Product Owner introduces the Developers to the customers and end-users, and other stakeholders so they can clarify what they were looking for.

The importance of checking in

Just by checking in with our customers and end users and other stakeholders, we can reassess whether we’re on the right track and what problem we’re trying to solve.

Ensure you are not just following the prescription of what someone thought a customer wanted at some point in time.

1. The Product Owner really should be doing a lot of work in product management;
2. Product ownership;
3. Commercial pricing;
4. Looking at customer analytics;
5. Visiting customers; and
6. Managing the expectations of stakeholders, and connecting with them. Managing their expectations in terms of uncertainty. Setting their expectations that we don’t know when we will be done. We’re committing Sprint by Sprint. We’re using an iterative, incremental approach. We’re trying to work empirically here.

We can use statistics like Monte Carlo probabilistic forecasting to have an idea when a particular amount of outcomes might be done, but actually, we don’t know. We’re just going to continually re-forecast and so on.

So there’s the big job there from the product owner to manage the optics and perception.

Why shouldn’t Scrum Masters be Product Owners?

Product Owner is a big job. Scrum Master is a big job.

In my opinion, it’s like mixing Scrum Master with Developer. What I often see is when a Developer is also a Scrum Master, the Scrum Master becomes the poor cousin. The person tends to do the misunderstood stances of a Scrum master and not the expected ones.

They do what people want them to do instead of what they should be doing, instead of acting like an ambassador for what Scrum is.

You can but shouldn’t.

Thank you.