Scrum Master vs Product Owner

Can a Team’s Product Owner Also Be Its Scrum Master?

Published on26 June 2020
Article intro

Introduction

Scrum is a popular buzzword in software development, but it’s also much more than that. It is a sophisticated methodology that can bring a development team a lot of value if used correctly. Today, we’ll discuss one of the many tricky questions involving the personnel roles used with this framework: can a project’s product owner also be its scrum master?

Let’s start with the definitions of each role. According to the Scrum Guide, “The product owner is responsible for maximizing the value of the product resulting from work of the development team, while the scrum master is responsible for promoting and supporting scrum as defined in the scrum guide.” These descriptions are quite broad, but that’s intentional. The Scrum Guide provides only a general overview of the methodology, giving individual developers freedom as far as details are concerned.

The handbook also outlines the area of responsibility for both roles:

  • The product owner’s mission is to manage product backlog, or the set of requirements that describe the functionality of the product. The product owner is responsible for ensuring that everyone in the team is on the same page about what they are to implement and how to prioritize each item. Moreover, the product owner’s aim is to maximize the value of the work that the team performs.
  • The scrum master is responsible for conveying Scrum theory, values and practices, and for facilitating interactions within the team, removing impediments that occur during development, and implementing changes that increase the team’s productivity.

The scrum master also has other duties that are broadly congruent with product owner’s: to make sure the team understands product backlog items and product value in general, to manage backlog effectively, to help the team in creating a high value product.

This overlap in duties takes us back to the main question: can one person perform both roles? The Scrum Guide does not specifically state that scrum master duties can’t be performed by any other member of the scrum team. Let’s assess this option from all possible angles.

First of all, to be a scrum master, a person has to know the objectives, values, and principles of the methodology from A to Z. This is the least of our concerns, as any team member can study all the peculiarities of the methodology and pass scrum certification assessment.

Nevertheless, we need to consider the core idea behind each role. A product owner’s focus is rather external: the PO needs to keep all stakeholders satisfied by making sure that the product being built is bringing value and meeting business goals. The scrum master’s activity, meanwhile, is concentrated on internal processes: improving the performance of the team as well as their communication and level of awareness. The scrum master is coaching, mentoring, and facilitating. The different focus of each role can cause a conflict of interests. The product owner’s goal is to deliver as many user stories within the sprint as possible, while scrum master is devoted to finding a sustainable pace and making sure the team delivers high quality increments. There is a possibility that, by combining duties, the scum master/product owner will become less of a leader and more of an administrator for the team, which is against agile values.

The skills needed to perform each role are also quite different. To manage and prioritize backlog, the product owner needs to analyze market data and have domain expertise in order to make the right decisions. For the scrum master, people management skills such as resolving conflict or facilitating communication come to the forefront.

Given the disparate priorities and skills associated with each role, there is a solid reason the Scrum Guide separates the two. Imposing the responsibilities of both roles onto one person may be overwhelming and cause distress. Unless the project is very moderate in terms of functionality and scale, very few individuals will be able to effectively cover such a wide range of duties.

Separating the two has logistical benefits, as well. Consider the situation in which the individual who works as both product own and scrum master is ill and cannot work for a week. With just one role or the other compromised, work can move forward; but with both roles unavailable, the project is likely to be disrupted dramatically.

The question to be asked here is why you’re considering combining the roles. If it’s simply a matter of saving time and money, then this solution is not likely to bring about fruitful results. But if you have other, well-grounded reasons to try this out, then why not? Go ahead and put up an experiment. Agile frameworks embrace change and welcome flexibility. However, be sure to gather regular feedback from the development team and stakeholders to make sure the experiment is working as expected and does not impede the flow of work.

To recap, the scrum framework doesn’t directly tell us that the scrum master and product owner roles can’t be combined. You are free to try it out. However, you need to be aware of certain pitfalls:

  • The product owner and scrum master have different goals. When the roles are separated, there is a healthy conflict between these team members. When one individual performs both roles, this balance is lost.
  • A person combining duties risks working overtime, becoming stressed, and not being able to do his work effectively.
  • The two roles require different sets of skills. Any individual is likely to be much more competent in one sphere than the other, which will affect his decisions.
  • The larger the project is, the riskier it is to entrust both areas of responsibility to the same person.

Has your team tried combining the two roles? If so, please let us know what you discovered!

Contributor
  • Olga Dyuba
    Olga Dyuba
    linkedProject Manager
  • Copy link

  • Twitter(X)
  • Facebook
  • LinkedIn

Succeed faster with Syberry.

Get in touch to discuss your vision—for your software and your business.