The Three Scrum Roles (Accountabilities)

Scrum has three roles: the Product Owner, the Scrum Master, and the Developers. Learn what each is accountable for and how they work together as one Scrum Team.

Scrum has three roles: the Product Owner, the Scrum Master, and the Developers. Together they form the Scrum Team — a small, cross-functional group that has everything it needs to deliver value each sprint. The current Scrum Guide calls these accountabilities rather than roles, to stress that each one describes what part of the team is responsible for, not a job title — but “Scrum roles” remains the everyday term.

The three Scrum roles

The Product Owner

The Product Owner is accountable for maximising the value of the product. They own the Product Backlog — what goes in it, how it is ordered, and that it is clear to everyone. They decide what the team builds and why, balancing the needs of customers, stakeholders, and the business. A good Product Owner says no often, so the team can focus on the most valuable work.

The Scrum Master

The Scrum Master is accountable for the Scrum Team’s effectiveness and for the way Scrum is practised. They are a servant leader, not a manager: they coach the team, facilitate the Scrum events, remove impediments, and protect the team’s focus. The Scrum Master usually facilitates the sprint retrospective and the other Scrum ceremonies, and works to build the psychological safety the team needs to improve.

The Developers

The Developers are the people who do the work of building the increment each sprint — whatever mix of skills that takes (engineering, design, testing, and more). They are accountable for how the work gets done: planning the sprint, creating a usable increment, and holding each other to the Definition of Done. In the 2020 Scrum Guide, “Developers” replaced the older term “Development Team,” and Scrum no longer recognises any sub-teams or titles within the group.

How the three roles work together

The three roles are deliberately balanced. The Product Owner points at what matters; the Developers decide how to build it; the Scrum Master makes sure the team works well and keeps improving. No one role is “in charge” of the others — they are peers with different accountabilities, and Scrum works best when each respects the others’ domain. The retrospective is where the whole Scrum Team steps back together to inspect how that collaboration is going and agree how to make it better.

Frequently asked questions about the Scrum roles

What are the three roles in Scrum?

Scrum has three roles, which the current Scrum Guide calls accountabilities: the Product Owner, the Scrum Master, and the Developers. Together they make up the Scrum Team. The Product Owner owns the what and the why, the Developers own the how, and the Scrum Master is accountable for the team’s effectiveness and for the way Scrum is practised.

What is the difference between a Scrum Master and a Product Owner?

The Product Owner maximises the value of the product — they own and order the Product Backlog and decide what the team builds and why. The Scrum Master is a servant leader accountable for the team’s effectiveness — they coach the team, facilitate the events (including the retrospective), and remove impediments. One focuses on the product, the other on how the team works.

Are there roles in Scrum or accountabilities?

Both terms describe the same three positions. Older Scrum material says “roles” (Product Owner, Scrum Master, Development Team). The 2020 Scrum Guide reframed these as “accountabilities” and renamed the Development Team to “Developers,” to stress that they describe what each part of the team is responsible for rather than a job title. Most teams still say “Scrum roles” day to day.

Who facilitates the sprint retrospective?

The Scrum Master usually facilitates the sprint retrospective, as part of their accountability for the team’s effectiveness and for the Scrum events running well. That said, facilitation can rotate — a mature team often shares it — but the Scrum Master remains accountable for making sure the retrospective happens and produces real improvement.