Product Owner, Scrum Master, Developers. The whole framework depends on respecting the boundaries between them — get them right and the team runs effortlessly; blur them and accountability collapses.
▸ Try the interactive toolScrum defines exactly three roles, and the entire framework depends on the boundaries between them being respected. Get the boundaries right and a team runs with a clarity that feels almost effortless — everyone knows what's theirs to decide and what's someone else's. Get them wrong — a Product Owner dictating how, a Scrum Master setting priorities — and accountability dissolves.
The Product Owner owns the what and the why: the backlog, the priorities, the value. The Developers own the how: the technical decisions and the work to deliver the increment. The Scrum Master owns the process: removing impediments, coaching the team, protecting the framework — a servant-leader, not a manager. The roles are deliberately separated so each has clear authority and no one undermines another's domain.
Product Owner — owns the what & why (backlog, priorities, value)
Developers — own the how (technical decisions, building the increment)
Scrum Master — owns the process (removes impediments, coaches, protects the framework)
Most Scrum dysfunction is a boundary violation — someone reaching into another role's domain, which strips that role of its authority and accountability.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| PO dictating the how | The Product Owner specifies technical solutions, stripping Developers' ownership. | Keeping PO to what/why leaves the how with those accountable for it. |
| Scrum Master setting priorities | The process role makes product calls it doesn't own. | A clear boundary keeps prioritisation with the Product Owner. |
| Developers ignoring the why | Building without understanding value or priority. | The PO's ownership of why keeps the team aimed at value. |
| Scrum Master as manager | Treated as a boss rather than a servant-leader; the team's autonomy erodes. | The servant-leader framing keeps the team self-organising. |
Make explicit who is the single Product Owner (what/why), who the Developers (how), and who the Scrum Master (process). Ambiguity here is the root of most Scrum dysfunction.
The PO sets priorities and explains value, then steps back from technical solutions. ‘Here's what and why; you decide how’ is the discipline that empowers Developers.
The Scrum Master serves the process and removes blockers — not sets priorities or makes product calls. Confusing this turns a coach into a competing manager.
Priorities without context produce mechanical building. The PO's job is ensuring Developers understand the value behind the what, so they make good local decisions.
The role succeeds by making the team more autonomous and unblocked — not by directing it. Measure it by impediments removed, not orders given.
A Product Owner, frustrated by how a feature was being built, started specifying the technical implementation in detail — which library, which architecture. The Developers, no longer trusted to own the how, disengaged from the technical decisions and simply built what they were told, including the flaws.
The boundary violation had stripped the Developers of both authority and accountability: they couldn't be responsible for technical quality they weren't allowed to decide. Restoring the boundary — the PO explaining the what and why, then trusting the team on the how — re-engaged them and improved both quality and ownership. The PO's frustration was real, but the fix was clarity of intent, not seizing the technical wheel.
The deliverable is explicit clarity on who owns what, why, how, and process — and a shared commitment to respect those boundaries.
| Role | Owns | Must NOT |
|---|---|---|
| Product Owner | What & why — backlog, priorities | Dictate the technical how |
| Developers | How — technical decisions, the build | Ignore value & priority |
| Scrum Master | Process — impediments, coaching | Set priorities or manage as a boss |
Scrum's roles aren't job titles — they're a deliberate separation of authority. The framework's effortless clarity, when it works, comes entirely from each role owning its domain and staying out of the others'.
The why-behind-the-boundary is accountability: you can only hold someone responsible for what they're empowered to decide. When a Product Owner dictates the how, the Developers can't be accountable for technical quality; when a Scrum Master sets priorities, the PO can't be accountable for value delivered. Each boundary violation transfers control without transferring responsibility, which is precisely how accountability dissolves and dysfunction sets in. The PM (usually the Product Owner in Scrum) demonstrates real skill not by reaching into the how when frustrated, but by getting the what and why so clear that the team can own the how well.
Dictating technical solutions strips Developers of ownership and accountability. Own what/why, trust them on how.
The process role isn't a product role. Keep prioritisation with the PO.
Servant-leader, not boss. Directing the team erodes the autonomy Scrum depends on.
Developers who don't understand value build mechanically. Make the why travel.
The three roles play defined parts in the five events (Tool 06).
Each artifact (Tool 05) has an owner among the three roles — the PO owns the product backlog, etc.
The PO/Developers what-vs-how boundary mirrors the PM–Tech Lead relationship (Tool 20).
‘Individuals and interactions’ (Tool 01) is why the Scrum Master serves rather than commands.
Recall a team you've seen where Scrum felt dysfunctional. Which boundary was being crossed — a PO dictating the how, a Scrum Master setting priorities, a Scrum Master acting as a boss?
Describe how restoring that one boundary would change the team's accountability.
Most Scrum dysfunction is a single boundary violation in disguise — finding which role reached into another's domain usually explains the whole mess.