Scrum Mystery: Product Owners and Scrum Masters

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
  • QA/UAT for all work the devs produce (testing to make sure it does what was asked and nothing else, before it gets released to the world)
  • Meeting with stakeholders to take in requests and needs
  • Answering questions or making decisions for the devs, about the details of sprint items they’re currently working on
  • Meeting with the devs to refine backlog items, getting them “ready” to pull into a sprint
  • Meeting with leadership to understand what is happening in the business, and learn about future developments that need to be planned for
  • Developing the product vision to define what exactly the software should do, and why
  • Maintaining a product roadmap to keep the next 3–6 months of development efforts in view
  • Negotiating with stakeholders about competing priorities, and often saying “yes” or “no” to requests while explaining why
  • Educating stakeholders and users about the software product, such as how to use new features
  • Attending all Scrum events

Traits important for Product Owners to embody are:

  • Comfortable being highly accountable and transparent
  • Can constantly re-prioritize by weighing many factors, ranging from straight data analysis to sensing and appropriately reacting to people’s emotions
  • Ability to manage a large amount of detailed work, while maintaining a strong strategic vision that all decisions are measured against
  • Easily earns the trust and respect from all types of people, and naturally encourages collaboration and open communication

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
  • Supporting the Product Owner by keeping them aware of any impediments the dev team runs into (ex. technical debt prevents a feature from being implemented, or management is trying to circumvent the Product Owner to demand non-sprint work be done ASAP)
  • Navigating the daily conflict between the dev team (who strive for technical quality) and the Product Owner (who wants more features).
  • Removing any barriers the dev team runs into (ex. they need a new software service integration in order to implement a new process, or someone’s out sick but the team needs an answer from them to move forward, or even that the team’s morale is low and they could really use some ice cream to cheer up)
  • Along the “cheering up” lines, strengthen the team by building trust and boosting morale, in whatever ways are best and appropriate for the team
  • Meeting with leadership and Product Owner to talk about how the dev team is, or is not, meeting their needs
  • Answering questions from stakeholders about potential software problems (bugs, etc.) and connecting with the dev team and Product Owner when necessary (ex. when it’s not a bug, it’s a feature flaw)
  • Gathering information about the Scrum team’s success and failure over time, to track possible problems and help everyone learn from mistakes/continually improve
  • Reporting on dev team’s progress to leadership and stakeholders, such as how much work they’re getting done in each sprint (“velocity”)
  • Educating stakeholders about the Scrum team, and how/why it works the way it does
  • Being the point of contact for anything dev/Scrum team related on a daily basis
  • Facilitating all Scrum events

Traits important for Scrum Masters to embody are:

  • Comfortable facing conflict head-on, and mediating towards real, actionable resolutions
  • Ability to coach and inspire people without the need for authority or power (peer-to-peer) — this is where the term “Servant Leader” really shines
  • Naturally curious, asking questions and always learning, especially around Scrum and leadership growth
  • Easily earns the trust and respect from all types of people, and naturally encourages collaboration and open communication (also important for Product Owners, but essential in both roles!)

Admittedly, this is a delicate topic for me to bring up, because it’s the case in my current position. I’m both Product Owner and Scrum Master (a “VALU-PAK” of sorts). My current organization is relatively new to Scrum, and owning full in-house software development, so this is an area ripe for improvement. I came on board knowing this challenge, and am optimistic that the team will adapt better to Scrum over time.

In case you’re considering implementing a similar Scrum hack in your own organization, here’s my experience summarized.

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

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

So far, I’ve been told I’ve done a good job and accomplished a lot. But I know the potential of both roles at full capacity. There’s simply not enough time or resources to do either of these roles justice if they aren’t two full-time jobs. In my current position, if I excel at one role, the other suffers because the balance of power is affected. 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).
  2. Talk to people who’ve worked on successful Scrum teams. Listen to their stories and insights, before hiring.
  3. Implement and hire for both roles as they should be (one of each, full time, and on the same team), and then actually let them do their jobs.

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.

Trust the process, trust the people. ✌️

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.