Roles

Close

Scrum has one team with three accountabilities: Product Owner, Scrum Master, and Developers.

Each accountability has a different focus. The Product Owner focuses on value. Developers create the increment. The Scrum Master helps the Scrum Team and organization use Scrum effectively.

Those accountabilities are separate, but they are not silos. Scrum works when the Product Owner, Scrum Master, and Developers collaborate as one Scrum Team.

What This Section Covers

This section gives you a high-level view of how the three Scrum roles relate to one another.

It covers:

  • How the Product Owner, Scrum Master, and Developers work together
  • Why the accountabilities are separate
  • Where the roles interact during Scrum events
  • How role clarity helps the Scrum Team make better decisions
  • Where to go deeper on each role

People often call these Scrum roles, and that term is still useful in everyday conversation. The more precise Scrum word is accountabilities. That word matters because Scrum is less concerned with job titles and more concerned with who is accountable for what.

How Scrum Roles Fit Together

Scrum roles work together by keeping three kinds of decisions visible.

The Product Owner keeps attention on value:

What matters most, and why?

Developers keep attention on delivery reality:

What can we responsibly complete, and how will we do the work well?

The Scrum Master keeps attention on Scrum effectiveness:

Are we using Scrum in a way that helps us inspect, adapt, and improve?

Those questions overlap constantly. Sprint Planning needs all three. Refinement needs the Product Owner and Developers in conversation. Sprint Reviews need product feedback, delivery transparency, and useful facilitation. Retrospectives need the whole Scrum Team to improve how it works.

The roles are separate not so people can stay in their own lanes, but so the Scrum Team can have better conversations.

One Scrum Team, Three Accountabilities

A Scrum Team is not a collection of separate departments.

The Product Owner, Scrum Master, and Developers are all part of one Scrum Team. They work together toward the Product Goal, Sprint Goal, and usable increments of product.

That matters because Scrum can become weaker when people talk as if the roles belong to different sides:

  • Product Owner versus Developers
  • Scrum Master versus management
  • Developers versus stakeholders
  • “The business” versus “the team”

Those divisions may reflect real organizational tension, but Scrum should not reinforce them.

The Product Owner needs Developers’ judgment about effort, risk, dependencies, quality, and technical options. Developers need the Product Owner’s understanding of users, customers, value, strategy, and tradeoffs. The Scrum Master helps the Scrum Team improve how those conversations happen.

The accountabilities are different. The team is one.

Pages in This Section

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work.

Go here for a deeper look at Product Owner responsibilities, Product Backlog ownership, stakeholder collaboration, product decisions, and common Product Owner challenges.

Learn about the Product Owner

Scrum Master

The Scrum Master helps the Scrum Team and organization use Scrum effectively.

Go here for a deeper look at Scrum Master responsibilities, coaching, facilitation, impediment removal, organizational influence, and how the role differs from project management.

Learn about the Scrum Master

Developers

Developers are the people on the Scrum Team who create the product increment.

Go here for a deeper look at who counts as a Developer in Scrum, how Developers own the Sprint Backlog, how they collaborate across specialties, and what it means to create a done increment.

Learn about Developers

How the Roles Work Together

The Product Owner, Scrum Master, and Developers interact constantly throughout a sprint.

The Product Owner brings clarity about value, priorities, users, customers, and desired outcomes. Developers bring the expertise needed to turn ideas into a usable product increment. The Scrum Master helps the Scrum Team use Scrum effectively and improve how it works together.

These accountabilities create a healthy balance of perspectives. The Product Owner helps the team focus on building the right thing. Developers help ensure it can be built responsibly and sustainably. The Scrum Master helps the team inspect, adapt, and continuously improve.

When Scrum is working well, decisions are informed by all three perspectives rather than dominated by just one. Clear accountabilities make collaboration easier because everyone understands who is responsible for what while still working toward shared goals as one Scrum Team.

Where Scrum Roles Overlap

Scrum roles are clear, but the work is collaborative. That means there will be overlap.

The Product Owner is accountable for the Product Backlog, but Developers help refine items, identify risks, estimate, split work, and clarify what can be done.

Developers are accountable for the Sprint Backlog and the increment, but the Product Owner helps clarify outcomes and make tradeoffs when new information appears.

The Scrum Master is accountable for Scrum effectiveness, but the whole Scrum Team is responsible for improving how it works.

That overlap is healthy. Problems begin when overlap becomes confusion.

For example, it is healthy for Developers to help refine the Product Backlog. It is not healthy for Developers to override the Product Owner’s ordering decisions.

It is healthy for the Product Owner to clarify what matters during the sprint. It is not healthy for the Product Owner to assign tasks to individual Developers.

It is healthy for the Scrum Master to help the Scrum Team notice weak collaboration. It is not healthy for the Scrum Master to become the team’s boss.

Why Scrum Keeps These Accountabilities Separate

Scrum separates these accountabilities because product development needs different kinds of judgment.

Someone needs to focus on value, users, stakeholders, and tradeoffs. That is the Product Owner.

Someone needs to focus on how to create a done increment. That is the Developers.

Someone needs to focus on whether Scrum is helping the team inspect, adapt, and improve. That is the Scrum Master.

These perspectives create useful tension. A Product Owner may want more in a sprint. Developers may see quality risks or hidden complexity. A Scrum Master may notice that the conversation is becoming pressure rather than planning.

Good Scrum Teams do not avoid that tension. They use it to make better decisions.

When Role Confusion Hurts Scrum

Role confusion usually shows up as a relationship problem, not just a terminology problem.

Accountability Is Unclear

If no one knows who is accountable for value, delivery, or Scrum effectiveness, decisions slow down or happen in the wrong place.

The Scrum Team may have many conversations but few clear decisions.

One Accountability Dominates the Others

Scrum works best when the accountabilities stay in balance.

If value conversations ignore delivery reality, the Scrum Team may overcommit. If delivery conversations ignore product value, the Scrum Team may optimize for work that matters less. If Scrum effectiveness is ignored, the Scrum Team may repeat the same problems sprint after sprint.

Roles Become Job Titles

A job title is not the same as a Scrum accountability.

A product manager may be the Product Owner. A tester, analyst, designer, or programmer may be one of the Developers. A manager might serve on a Scrum Team, but the person still needs to respect the accountability they are fulfilling.

The question is not only what someone’s title is. The question is what they are accountable for on the Scrum Team.

Leaders Bypass the Scrum Team

Managers and leaders still matter in Scrum. They shape goals, staffing, strategy, constraints, and organizational design.

But Scrum becomes weaker when leaders bypass the Product Owner, assign work directly to Developers, or treat the Scrum Master as a project manager. Those behaviors replace Scrum accountabilities instead of supporting them.

One Person Holds Multiple Accountabilities

One person may temporarily cover more than one Scrum accountability, especially in a small organization. But the tradeoffs should be visible.

This is especially important when one person tries to be both Product Owner and Scrum Master. One accountability focuses on product value and tradeoffs. The other focuses on Scrum effectiveness, facilitation, coaching, and improvement.

That tension can be useful when it is held by different people. It is harder when one person has to represent both perspectives.

How Leaders Can Support Scrum Roles

Leaders can help Scrum roles work by supporting the relationships among the accountabilities.

That includes:

  • Giving the Product Owner enough authority to make product tradeoffs
  • Staffing Scrum Teams with the skills needed to create done increments
  • Keeping Scrum Teams stable enough to learn how to work well together
  • Avoiding direct task assignment to Developers
  • Supporting the Scrum Master when organizational impediments need attention
  • Rewarding team outcomes rather than only individual output
  • Making strategic goals clear enough for Product Owners to order work well

Many role problems are not caused by the Scrum Team alone. They are caused by an organization that has kept old decision patterns while adopting Scrum language.

Are the Scrum Roles Working Together?

Use these questions to find the next conversation your Scrum Team may need:

  • Can the Product Owner, Scrum Master, and Developers each explain what the others are accountable for?
  • Does the Product Owner make ordering decisions with useful input from Developers and stakeholders?
  • Do Developers own the sprint plan rather than wait for work to be assigned?
  • Does the Scrum Master help improve the Scrum Team’s effectiveness without becoming the team’s boss?
  • Are role boundaries clear enough to support collaboration rather than create silos?
  • Do Scrum events bring the right accountabilities into the right conversations?
  • Do leaders support the Scrum Team’s accountabilities instead of bypassing them?
  • Does the Scrum Team talk openly when role confusion gets in the way?

Use the answers to decide whether unclear accountabilities are weakening collaboration.

FAQ

What are the three Scrum roles?

The three Scrum accountabilities are Product Owner, Scrum Master, and Developers.

People often call them Scrum roles. The important point is that each accountability has a different focus and all three work together on one Scrum Team.

Why does Scrum use accountabilities instead of roles?

Accountability emphasizes responsibility.

A role can sound like a job title. An accountability makes clear what someone is responsible for on the Scrum Team.

Are Scrum roles the same as job titles?

Not necessarily.

Scrum roles describe accountabilities on a Scrum Team. Job titles describe positions in an organization. A person may have a job title such as product manager, tester, designer, developer, or engineering manager while serving in one of the Scrum accountabilities.

Can one person have more than one Scrum accountability?

Sometimes, especially temporarily or in small organizations. But the tradeoffs should be visible.

Combining accountabilities can create conflicts, especially when one person is both Product Owner and Scrum Master.

Who decides what goes into a sprint?

The Product Owner explains priorities and desired outcomes. Developers decide how much work they believe they can complete during the sprint.

Sprint Planning should be collaborative, but Developers own the forecast of what can be done.

Who helps when the roles are confused?

The Scrum Master should help the Scrum Team notice and address role confusion.

But fixing role confusion may also require the Product Owner, Developers, managers, leaders, or stakeholders to change how they work with the Scrum Team.