Image for post
Image for post

Scrum Mystery: Product Owners and Scrum Masters

Sarah Crisp
Jun 13, 2017 · 7 min read

Scrum is great. Simple and straightforward. When used properly, it can work wonders for teams. However, there’s one key part of Scrum I’ve seen people struggle to grasp, which is the importance and difference of the Product Owner and Scrum Master roles.

This lack of understanding means that these positions aren’t properly planned for, trained for, or hired for. The people who end up in these positions (regardless of skill or experience) will fail to some degree. This harms both the team and the software product!

Let’s start off with some clarification for both roles.

Product Owner:

The Product Owner steers the ship. They know the destination, the route to get there, and the risks along the way.

The Product Owner fully owns the product vision and backlog. They make decisions based on both wide and deep knowledge about the business, and the technical product. They extract and manage all possible knowledge across the entire organization and user base, in order to create and prioritize work for the developers. They’re the #1 stakeholder, and must always be available for the dev team throughout the development cycle. They often have the final say in matters such as QA acceptance and when features get released.

Being a Product Owner is highly complex and technical in nature, despite the core function of being a business representative for the dev team.

In just one day, a good Product Owner will likely handle most or all of these types of work:

  • Technical writing of backlog items

Traits important for Product Owners to embody are:

  • Comfortable being highly accountable and transparent

Scrum Master:

The Scrum Master keeps the ship intact, as it naturally degrades over time, weathers storms, and sustains attacks from the outside.

The Scrum Master (also commonly known as “The Protector” or “Servant Leader”) is responsible for the daily life and long-term success of the Scrum team. It’s a dynamic role that adapts constantly to the needs of the team and business, and can look very different day-to-day as they address different challenges.

They’re the coach that assures everyone plays their respective positions, for the good of the team. They keep the rest of the business informed about what and how the team’s doing. They also handle any conflict that arises in or around the team.

Here’s a common example of in-team conflict:

The Product Owner creates the what/why/when of the dev work, but doesn’t dictate HOW anything gets built, beyond what the end user experience or result should be. A controlling or micromanaging Product Owner may easily cross this boundary and make demands that interfere with the sprint. This requires a strong Scrum Master to stand firmly between the Product Owner and the devs, making space and setting expectations.

A Scrum Master’s additionally responsible for handling anything that could possibly distract or derail the devs from their work, and making sure those blockers are removed. For instance, if your product has a lot of known bugs or technical debt, the Scrum Master will work with the Product Owner to help prioritize those items among the backlog of feature work, and assist the stakeholders struggling with the repercussions before they can get resolved.

In just one day, a good Scrum Master will likely handle most or all of these types of work:

  • Reviewing the backlog with the Product Owner, helping split backlog items into smaller increments of work, assisting with prioritization

Traits important for Scrum Masters to embody are:

  • Comfortable facing conflict head-on, and mediating towards real, actionable resolutions

In case you’re considering implementing a Scrum hack by combining these two roles in your own organization, here’s some insight from my time wearing both hats.

As Product Owner, I couldn’t make enough time to keep the backlog clean, relevant, and prioritized below the top 20%. I was never able to completely clean out the abyss of mystery JIRA tickets left by a previous Product Owner. I spent most of my time chasing down answers and approvals from stakeholders, but rarely had enough time to really refine the information I gathered before discussing with devs. I had no in-office time for product planning or strategy, so I found myself doing most of my non-admin Product Owner work (the fun stuff!) on nights and weekends.

As Scrum Master, I couldn’t make enough time to protect my team, communicate with the business, and be effecting positive change. Besides facilitating sprints and Scrum events, I spent most of my time in office helping out my devs with team issues (interpersonal coaching), and fielding questions or handling urgent issues from stakeholders.

I was told I did a good job and accomplished a lot during that time. But I know the potential of both roles at full capacity, and was disappointed in the greater progress we missed out on! There’s simply not enough time or resources to do either of these roles justice if they aren’t two full-time jobs. In a combined-role position, excelling at one role means the other suffers, because the balance is affected. Doing an OK job in both is the only way to make that situation really work for everyone. The two roles are meant to have tension, balance each other out, and shoulder different challenges and responsibilities.

You wouldn’t skimp on, or combine, the offense and defense of a sports team… this is the same concept!

That brings us back to the point of having both Product Owner and Scrum Master roles.

Scrum teams have a distinct structure for good reason. It relieves the pain points from each role by defining responsibilities clearly.

It’s pretty clear what the role of developers are on a software Scrum team. The confusion I’ve observed in people unfamiliar with Product Owners and Scrum Masters is largely because the roles are very intentionally NOT the same as any other roles in an organization. They’re relatively new to the business world, in fact (15 years or so, gaining momentum in recent years).

Product Owners and Scrum Masters are often lumped together and generalized, based on generic bullet points people can cognitively align with more traditional business roles (ex. “Project Manager” or “Business Analyst” or “Team Lead”).

How can you avoid this problem? Here are the basic steps:

  1. Do enough initial research that you can understand what the basic responsibilities of each role are, and how they differ in context (see below for a start).

Key takeaways:

Don’t ignore the importance and true meaning behind two out of three defined roles on a Scrum team.

Learn from people with experience in these roles before making any assumptions or “going off book.”

Keep in mind that the Product Owner and Scrum Master are members of the team, not usually the managers of anyone on the team. This allows for a healthy power balance, with complete transparency and trust from the get-go. If you end up in a Scrum role with team management responsibilities, be highly sensitive and respectful of those boundaries!

Trust the process, trust the people. ✌️


Shared discoveries, patterns, and how-to’s from the…

Sarah Crisp

Written by

Tech product leader, book reader, pet lover, sci fi enthusiast, 🏳️‍🌈



Shared discoveries, patterns, and how-to’s from the Marmoset software team to you.

Sarah Crisp

Written by

Tech product leader, book reader, pet lover, sci fi enthusiast, 🏳️‍🌈



Shared discoveries, patterns, and how-to’s from the Marmoset software team to you.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store