The Product Owner and the Scrum Master (referred to as "PO" and "SM" in this article) are two fundamental roles in agile methodologies. Initially created within the Scrum framework, these roles have evolved beyond their original purpose, now embodying an entire philosophy of software development—sometimes conjuring images of walls covered in sticky notes and epic sprint demos.
Ideally, the SM and PO form a dynamic duo that enables a development team to embrace agile principles quickly, take ownership of their responsibilities, and build the right product the right way.
However, this ideal scenario is far from universal. That’s why we’re sharing this article—intended for anyone in an agile team—looking to improve collaboration between the SM and PO.
A Look at the History of the Scrum Master and Product Owner
Originally described in the guide by Ken Schwaber and Jeff Sutherland, the Scrum Master and Product Owner roles were designed to support a team operating within Scrum.
Unlike the Product Owner, whose role is permanent and integral to the team, the Scrum Master role can be filled by any team member—except the PO. Regardless of who takes on the SM role, both positions share the responsibility of ensuring the team functions effectively.
In a nutshell:
- The Product Owner ensures that the right features are built in the right order.
- The Scrum Master guarantees that the team operates smoothly and adheres to the organization's agile methodology.
While these theoretical distinctions are clear, we often see collaboration issues in our work due to various contextual factors. Let's dive into some of the most common situations that can cause friction.
Four common situations where the SM-PO roles break down
When the boundaries between the SM and PO roles are blurry
A recurring issue is the lack of clear role definitions for the PO and SM. This often happens when a company moves to an "agile mode" and assigns a PO and an SM to each development team without a clear framework.
Our suggestion:
Stick to the role definitions outlined above and use the following criteria to clarify responsibilities when confusion arises:
- If a task relates to enforcing Scrum practices and team autonomy → it’s the Scrum Master’s job.
- If a task concerns roadmap alignment or the quality of deliverables per sprint → it’s the Product Owner’s responsibility.
👉 Some cases are trickier to define. For example, who is responsible for implementing automated functional tests? This impacts both team autonomy and release quality.
We believe this falls under the SM’s responsibilities, while still requiring close collaboration with the PO. Although it directly affects release quality, automation ultimately empowers the team to take ownership of quality in the long run.
When the team doesn't understand Scrum
Another common challenge—especially when transitioning to agile—is that development teams may not fully grasp Scrum principles.
This often leads to pushback on agile ceremonies, with complaints like:
❌ "Daily stand-ups are useless."
❌ "Why estimate in story points? It feels childish."
Our Recommendation:
The Shu Ha Ri philosophy (learning stages in agile) is great in theory but often misapplied in practice. Teams need a safe space for discussion and a deep understanding of their actual needs before rituals are imposed.
The Scrum Master should ask:
✔️ What is the team’s relationship with the business and stakeholders?
✔️ How frequently are releases deployed?
✔️ How cross-functional is the team?
👉 Taking time to assess these factors upfront will make ceremonies more relevant.
It’s far better to adapt Scrum to the team than to enforce a rigid, “by-the-book” approach that eventually leads to resentment (“Scrum is horrible”).
When the Product Owner avoids technical tasks
Sometimes, Product Owners are excluded from technical discussions, leading to a backlog split into two parallel streams:
- Functional user stories
- Technical tasks (with separate allocations of story points)
We believe this is a bad practice.
Our Recommendation:
If your team operates this way, it likely means the PO is perceived as disengaged from technical concerns—which is a real problem.
The PO must:
✔️ Understand technical tasks and not view them as a threat to the "functional backlog."
✔️ Prioritize them alongside functional tasks based on customer and business impact.
Likewise, the development team should think in terms of “outcomes” when evaluating technical work:
❓ What value will this bring to customers or the team?
❓ What are the risks of not doing this technical task?
👉 Do not separate sprint capacity into "technical tasks" vs. "business tasks."
Prioritization should occur within the same backlog, with trade-offs made by the PO and stakeholders.
If the PO lacks technical knowledge, they should receive training. Since this impacts team autonomy, the Scrum Master should facilitate this learning.
Find out more about our Product Owner training and our Product Manager training.
When a mature team no Longer needs a Scrum Master
In some companies, every development team is assigned a full-time Scrum Master. In mature teams, this can lead the SM to shift toward support tasks (e.g., ordering servers, writing documentation, refining user stories, reviewing commits) rather than reassessing their role.
Our Recommendation:
👉 If a high-performing team is self-sufficient and delivers quality work, it’s okay to operate without a dedicated Scrum Master.
However, if the team struggles with:
❌ Unfinished sprints
❌ Lack of clarity on the purpose of their work
Then, a Scrum Master should step in to help the team grow—not take over their responsibilities.
🚀 Instead of “filling the gaps,” the SM should focus on enabling the team to handle missing tasks sustainably.
Key questions for an SM to ask:
✔️ Is documentation well-written?
✔️ Is QA being handled effectively?
✔️ Are team members focusing on their actual roles?
✔️ Are relationships with stakeholders and other teams healthy?
👉 Agile ceremonies (daily stand-ups, demos, retrospectives, grooming) don’t require a permanent SM—they can be rotated within the team.
Conclusion: self-organized teams are the goal
As you will have noticed, the resolution of these situations is always made possible by listening and the desire to make teams autonomous and efficient.
Although indispensable at a certain point, scaling up agility will increase the chances that the dysfunctions cited in this article will appear in your teams. If this is the case, it's important to bear in mind that a methodological framework - even if it's reassuring and helps less mature profiles to become more competent - will never be perfect for you: allow your teams to take initiative and innovate in the way they manage their difficulties!
