The Scrum Master + Product Owner

Some companies think they can get away with having one person perform the roles of Scrum master and product owner. Folks in management might say, “We don’t have room/budget for two new positions so let’s combine those responsibilities into a single role: Scrum master + product owner.” They might even want to combine other positions into this role, too, such as project manager, architect, or even developer.

When push comes to shove, which role will they choose? Will they revert to their Scrum master accountabilities or will the product owner win out? Either way, the Scrum team will lose out on critical interactions that need to happen during sprints.

Here are the kinds of things that Scrum masters commonly discuss with development team members, stakeholders, and management:

• Development team: Upholding Scrum and ensuring that the team is optimized for empirical process control.

• Stakeholders: Creating an understanding of the complex domain of work and showing them how necessary it is to have empirical process control.

• Management: Collaborating on the organizational changes that are necessary for Scrum to succeed.

By contrast, here are the kinds of things that product owners should discuss with those same folks:

• Development team: The vision and direction of the product and how the product owner has translated that vision and direction into the product backlog.

• Stakeholders: Collaborating and keeping actively engaged with the direction of the product.

• Management: Working through the budgeting process.

Notice that these conversations are wildly different, and the various topics require totally different approaches. For example, take the conversations with management: If you are speaking to them about the budgeting process, you would use very different techniques than you would if you were proposing organizational changes. A single person can’t effectively focus on both types of conversations.

What’s missing from the table is the interactions that a Scrum master and product owner should be having with each other. There are several important interactions that a product owner and Scrum master need to have but can’t if they are the same person. The product owner/Scrum master will have nowhere to turn when they need help and the product will suffer as a consequence.

A Scrum master serves the product owner in a multitude of ways. Here are a few examples:

• Facilitating interactions between the product owner and the development team.

• Helping the product owner identify and work with stakeholders.

• Working with the product owner to find ways to do proper product backlog management.

• Finding ways to make the product backlog transparent to the dev team and stakeholders.

• Teaching Scrum to the product owner.

• Coaching the product owner on agile product management.

Product owner is a full-time job that requires attention to many things outside the bounds of Scrum. A product owner is an agile product manager who evaluates the market and internal corporation with an eye on value maximization. The PO works with stakeholders to keep them informed while gathering their opinions about the direction of the product. They collaborate with the development team to help them understand the direction of the product and pave a path to get there. He creates the vision, road maps, and release plans; manages the budget, evaluates total cost of ownership, estimates return on investment, and so on.

With all of this work to do, there’s no way a product owner can complete these tasks and the tasks expected of a Scrum master. To make people aware of this problem, try this activity (it helps to have friends for this exercise, so grab some other Scrum masters):

Think about the Scrum master role and brainstorm every task someone in that role may perform during a sprint, and create a sticky note for each task. Once you’ve exhausted this list, take a break. When you return, move to the product owner role and do the same thing with different color sticky notes to differentiate between the roles. Then look at what you’ve created and ask:

• Are there any similarities in work?
• Are there any conflicts of interest caused by performing both roles?
• Can one person do all of these tasks?
• What and/or who may suffer if one person tries?

Now walk through the Scrum values and ask if it’s really possible to focus on both roles and the work that needs to be done for each role during a sprint. Can you truly commit to performing this work at high level? Will you be open enough with the Scrum team to admit that you’re struggling? Will you show the courage to admit when you don’t know what to do next? Do you have enough respect for the customers and stakeholders to stop performing both roles if product delivery is suffering?

If you can’t honestly answer yes to these questions, as much as it may hurt, advocate for your role (or the person assuming both of these roles) to be split into two roles.