Skip to content
5 min read·Lesson 3 of 10

Scrum Roles

The three accountabilities in Scrum: Product Owner, Scrum Master, and Developers. Who does what, who owns what, and where teams go wrong.

Scrum is a small framework defined in the Scrum Guide. It has three accountabilities (older versions called them "roles"), five events, and three artifacts. This lesson covers the people; the next two cover the events and artifacts.

The Scrum Team

A Scrum Team is one Product Owner, one Scrum Master, and Developers — typically 10 or fewer total. It is cross-functional (all skills needed to deliver value sit inside the team) and self-managing (it decides who does what, when, and how).

The Product Owner

One person, accountable for maximising the value of the product.

Responsibilities

  • Develop and communicate the Product Goal.
  • Create and clearly express Product Backlog items.
  • Order the backlog by value, risk, and dependency.
  • Ensure the backlog is visible, transparent, and understood.
  • Decide what is "done" enough to ship from the customer perspective.

Authority

The Product Owner has the final say on backlog ordering. Stakeholders influence; the Product Owner decides. If anyone else can override the order, the role is not real.

Common dysfunctions

  • Proxy Product Owner. Someone who relays decisions but cannot make them. The team is permanently waiting.
  • Committee Product Owner. Three people share the role; nothing decides until all three agree.
  • Order-taker Product Owner. Whoever shouts loudest gets prioritised. The team has no compass.
  • Absent Product Owner. Available only at sprint planning. The team makes guesses for the rest of the sprint.

The Scrum Master

One person, accountable for the Scrum Team's effectiveness. The Scrum Master is a servant-leader, not a manager.

Responsibilities

  • Coach the team in Scrum theory and practice.
  • Help the team focus on creating high-value increments.
  • Remove impediments to the team's progress.
  • Facilitate Scrum events as needed.
  • Help the organisation understand and apply Scrum.

Authority

The Scrum Master has no authority over what the team builds (that's the Product Owner) or how individuals do their work (that's the Developers). Authority is in service of effectiveness — facilitation, coaching, removing organisational blockers.

Common dysfunctions

  • Scrum Master as project manager. Assigns tasks, reports status up, holds people accountable to estimates. This is not Scrum.
  • Scrum Master as scribe. Updates Jira tickets all day; never coaches.
  • Scrum Master as ceremony enforcer. Runs every meeting; team has no say in how the team runs.
  • Part-time Scrum Master. Senior engineer doing both. One side suffers; usually the coaching.

Developers

The people committed to creating any aspect of a usable Increment each Sprint. "Developer" in Scrum is a generic term — it includes engineers, designers, testers, ops, anyone whose skills go into the increment.

Responsibilities

  • Create a plan for the Sprint (the Sprint Backlog).
  • Instil quality by adhering to a Definition of Done.
  • Adapt their plan each day toward the Sprint Goal.
  • Hold each other accountable as professionals.

Self-management

Developers decide who does what, what order to do it in, what tools to use, what design to follow. The Product Owner says what is needed and why; Developers decide how.

Common dysfunctions

  • Specialist silos. Frontend can't help backend; tester can't pair on code. Cross-functionality erodes.
  • Heroes and free riders. One person carries the team; others coast.
  • "Not my job" culture. The increment fails because the test environment broke and "that's the platform team."

Roles Outside the Team

Scrum identifies stakeholders: anyone with an interest in the product but not in the Scrum Team. Customers, executives, other teams. Stakeholders engage primarily through the Sprint Review.

Note: there is no "manager" or "PM" role inside Scrum. Those roles often exist around the team — managing careers, orchestrating cross-team work, handling budgets — but they sit outside the Scrum framework.

Three People, One Goal

The accountabilities exist because each focuses on a different aspect of value creation:

RoleFocusQuestion they ask
Product OwnerValueAre we building the right thing?
DevelopersQualityAre we building the thing right?
Scrum MasterEffectivenessAre we able to keep building well?

When the three accountabilities collaborate well, the team has both direction and capability. When they conflict — typical when one role is missing or compromised — the framework starts to creak.

Cert Mapping

CertScope
PSM IRoles are heavily tested; Scrum Guide is canonical
PMI-ACPRoles plus broader Agile leadership
SAFe AgilistRoles plus RTE, Product Manager, Business Owner

The next lesson covers the events that give Scrum its rhythm.

Key Takeaways

  • Scrum has three accountabilities: Product Owner, Scrum Master, Developers.
  • The Product Owner owns the product backlog and value decisions.
  • The Scrum Master is a coach and impediment-remover, not a project manager.
  • Developers own how the work gets done.
  • Confusion between roles — especially Scrum Master vs PM — causes most Scrum dysfunction.

Test your knowledge

Try exam-style practice questions to reinforce what you've learned.

Practice Questions →