Most agile teams use Scrum, and Scrum has exactly three roles: one Product Owner, one Scrum Master, and the Developers who do the work. Everyone else with a stake in the product, from customers to managers, works with the team but isn't part of it.
The roles are easy to list and easy to blur. A Product Owner turns out to be a committee, the Scrum Master becomes the team's note-taker, and the Developers wait to be told what to do next. This guide explains what each role owns and decides, as the Scrum Guide defines them, who else works around the team, how roles work in Kanban, and who does what in each meeting, with an example team.
The Three Roles at a Glance
| Role | Accountable for | Decides | Isn't |
|---|---|---|---|
| Product Owner | The value of the product: the Product Goal and the Product Backlog | What the team works on next, and in what order | A committee, or a go-between who can't say no |
| Scrum Master | The team's effectiveness, and how well it uses Scrum | Nothing about the product; helps the team decide how to improve | The team's manager, or its secretary |
| Developers | A usable increment every sprint, built to the team's Definition of Done | How to do the work, and who does which part | People who wait to be handed tasks |
The 2020 edition of the Scrum Guide calls these accountabilities rather than roles, and it replaced the old "Development Team" with "Developers", so that a Scrum team is one team with no team inside it. Most people still say roles, and so does this guide.
Product Owner
The Product Owner is accountable for the value of what the team builds. In practice, that means owning the Product Backlog, the single ordered list of everything the product might need, and being the person who decides what goes at the top. The Scrum Guide lists four parts to that job:
- Setting the Product Goal, the longer-term objective the backlog works toward, and making sure everyone knows it.
- Writing backlog items, or getting them written, so the team understands what each one is for.
- Ordering the backlog, so the most valuable work comes first.
- Keeping the backlog visible and understood by everyone who has a stake in it.
The Product Owner is one person, not a committee. Sales, support and the CEO can all try to change the order of the backlog, but they do it by convincing the Product Owner. The Product Owner can hand some of the work to others, such as writing items, and still answers for the result. So the role needs someone with the authority to say no, and the time to talk to customers and stakeholders every week.
Scrum Master
The Scrum Master is accountable for the team's effectiveness, and for the team using Scrum as it's meant to be used. The Scrum Guide calls Scrum Masters "true leaders who serve the Scrum Team and the larger organization", and the service goes three ways:
- To the team: coaching it to manage itself, keeping it focused on finishing work that meets the Definition of Done, getting impediments removed, and making sure the meetings happen, stay useful and stay within their time.
- To the Product Owner: helping with ways to set the Product Goal and keep the backlog clear and ordered.
- To the organization: helping managers and other teams understand how the team works, and removing the obstacles between them.
A Scrum Master doesn't assign work, set deadlines or report on people. When the team asks "who should take this?", a good Scrum Master hands the question back to the team. One Scrum Master can serve more than one team, and in a small team the Scrum Master often builds things too: the Scrum Guide says that a Product Owner or Scrum Master who works on items in the sprint takes part as a Developer.
Developers
The Developers are everyone on the team who builds the product: engineers, designers, testers, writers, analysts. The title isn't about code. Together, they're accountable for:
- Planning the sprint: choosing the work and deciding how to do it.
- Building to the team's Definition of Done, the shared standard for when a piece of work is finished.
- Adjusting the plan every day to reach the sprint's goal.
- Holding each other to that standard.
Developers manage themselves. Nobody outside the team tells them who does which task; they decide together, and they share the responsibility for the result. The team is also cross-functional: between them, the Developers have every skill needed to finish an item, so nothing waits on a separate design team or testing team.
How Big Is an Agile Team?
The Scrum Guide says a Scrum team is "typically 10 or fewer people", Product Owner and Scrum Master included. The earlier edition put it at three to nine Developers. Past that size, communication slows down and the daily meeting stops being useful. When a product needs more people, split them into several teams that share one Product Goal, one Product Backlog and one Product Owner.
The Roles Around the Team
Scrum only defines the three roles inside the team. Plenty of other people shape the work from outside it:
- Customers, users and sponsors. The people the product is for and the people paying for it. They see the results at the sprint review, and their feedback changes what the Product Owner puts next.
- Managers. Line managers still hire, develop people and fix problems the team can't fix alone, such as a missing skill or a conflicting priority. They don't assign the sprint's work.
- Project managers. Scrum has no project manager role: the Product Owner owns scope and priorities, the Developers own the plan, and the Scrum Master owns the process. In practice, project managers often become Product Owners or Scrum Masters, or coordinate the things that span several teams, such as budgets, vendors and release dates.
- Agile coaches. Coaches who work with several teams and with leadership, usually when a whole company changes how it works.
- Shared specialists. A security expert or a data analyst who helps several teams works with each team as needed, without being one of its Developers.
Frameworks for scaling agile across many teams add roles for coordinating them; SAFe's Release Train Engineer is the best known. A single team doesn't need any of them.
Roles in Kanban
Kanban doesn't prescribe any roles. The Kanban Guide asks a team to make its work visible, limit the work in progress, and actively manage how work flows, and leaves the job titles alone. A team that adopts Kanban keeps the roles it already has.
The Kanban Method from Kanban University describes two optional roles, which map closely to Scrum's: a service request manager, who decides what work comes in next, like a Product Owner; and a service delivery manager, who keeps the work flowing, like a Scrum Master.
Example: One Sprint at Kestrel Travel
Kestrel Travel is a fictional company with a travel app. Its check-in team has seven people, and works in two-week sprints toward one Product Goal: travelers can check in for any flight from the app.
| Person | Role | Also does |
|---|---|---|
| Ana | Product Owner | Talks to travelers and to the airline partnerships team every week |
| Ravi | Scrum Master | Also serves the payments team |
| Lena, Marco, Joy | Developers | The iOS, Android and back-end engineers |
| Sam | Developer | The designer |
| Kofi | Developer | Tests the app on real phones |
For sprint 9, Ana proposes the most valuable next step: a traveler with a one-way ticket can check in and keep the boarding pass on their phone. This is who does what in each of the sprint's meetings:
| Meeting | Ana, Product Owner | Ravi, Scrum Master | The Developers |
|---|---|---|---|
| Sprint planning | Explains why one-way check-in matters most now, and answers questions about it | Keeps the meeting to its time and makes sure it ends with a plan | Choose the items they can finish, agree the sprint goal with Ana, and plan the first days' work |
| Daily scrum | Doesn't need to attend | Makes sure it happens, and that it stays within 15 minutes | Check progress toward the sprint goal and change the plan if they need to |
| Backlog refinement | Explains the next items, reorders the backlog | Coaches the team on splitting big items | Ask questions, estimate the items, split the ones that are too big |
| Sprint review | Invites stakeholders, discusses what changes in the backlog | Facilitates, if the team wants him to | Show the working check-in and hear the stakeholders' feedback |
| Retrospective | Takes part as a member of the team | Facilitates | Pick one or two changes to try in the next sprint |
On day two, Joy finds that the team still has no test account for the airline's check-in system. She raises it at the daily scrum, and Ravi takes it on: getting the account is now his job, so the Developers don't spend the sprint chasing it.
Set Up the Roles in Redbooth
The roles are easier to keep when the board shows who owns what. In Redbooth, the Kestrel team uses one workspace for the check-in product, with the whole team as members, and three task lists:
- Product backlog, kept by Ana. Each item is a task, with the details in its description and the questions in its comments. Ana keeps the most valuable items at the top.
- One list per sprint. At sprint planning, the Developers move the items they choose into "Sprint 9", break each one into subtasks, assign themselves, and give each task dates inside the sprint.
- Impediments, owned by Ravi. Anything that blocks the team becomes a task assigned to him, so nobody has to raise the same problem at every daily scrum, and everyone can see when it's solved.
In the board view, the three lists sit side by side, and every card shows who has it:
If the team writes its roles down, a team charter is the place for them, together with how the team will decide when it disagrees.
Mistakes That Blur the Roles
- A Product Owner by committee. When three managers share the role, the backlog has no order, and the team learns to wait for them to agree.
- A Product Owner who can't decide. A go-between who checks every choice with someone else slows every sprint down.
- A Scrum Master who manages. Assigning tasks and chasing dates teaches the team to stop managing itself.
- Teams inside the team. A separate testing group at the end of the sprint brings back the handoffs Scrum is meant to remove.
- People spread over too many teams. Someone on four teams belongs to none of them, and each team plans around their absence.
Questions People Ask
What are the three roles in Scrum?
The Product Owner, who decides what the team works on and in what order; the Scrum Master, who makes the team effective; and the Developers, who build the product. The Scrum Guide calls them accountabilities.
Who are the members of an agile team?
Everyone needed to turn backlog items into a finished, usable result. In Scrum that's the Product Owner, the Scrum Master and the Developers, typically ten people or fewer in all. Customers, sponsors and managers work closely with the team but aren't part of it.
Is the Scrum Master a project manager?
No. A Scrum Master doesn't plan the work, assign it or report on people; the Developers plan their own work, and the Product Owner decides the priorities. The Scrum Master coaches the team and removes what slows it down.
Can the Product Owner and the Scrum Master be the same person?
The Scrum Guide doesn't forbid it, but it's rarely a good idea. The Product Owner pushes for more value; the Scrum Master protects the way the team works. One person doing both usually loses one of those two voices.
Does Kanban have roles?
No. The Kanban Guide doesn't prescribe roles, so a team keeps the ones it has. The Kanban Method describes two optional ones, the service request manager and the service delivery manager.
Before your next sprint planning, ask the team three questions: who orders the backlog, who removes what blocks us, and who decides how the work gets done. If the answers aren't one name, one name and "all of us", start there.