Scrum Roles: Product Owner, Scrum Master and Developers Explained

Scrum defines one team with three accountabilities: the Product Owner, the Scrum Master and the Developers. The words matter. The Scrum Guide calls them accountabilities, not job titles or roles in an organisation chart. "Accountability" means the person answers for an outcome; it does not mean they do all the work themselves.

Many Scrum problems come from misunderstanding these accountabilities: a Product Owner who cannot make decisions, a Scrum Master who acts as a project manager, Developers who wait to be told what to do. This guide explains each accountability as the Scrum Guide describes it, what it looks like in practice, the common mistakes, the skills each needs, how they work together through Scrum's events, and which course suits each.

The Scrum Team

According to the Scrum Guide, a Scrum Team is small, cross-functional and self-managing.

• Small: typically 10 or fewer people. Smaller teams communicate better and are more productive. If a team grows too large, the Scrum Guide suggests reorganising into multiple cohesive Scrum Teams that share the same Product Goal, Product Backlog and Product Owner.
• Cross-functional: the team has all the skills needed to create value each Sprint.
• Self-managing: the team decides internally who does what, when and how.

A Scrum Team has one Product Owner, one Scrum Master and Developers. There are no sub-teams or hierarchies. The whole team is accountable for creating a valuable, useful Increment every Sprint.

Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. The Scrum Guide says this includes effective Product Backlog management:

• Developing and explicitly communicating the Product Goal.
• Creating and clearly communicating Product Backlog items.
• Ordering Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do this work or delegate it to others, but remains accountable. The Product Owner is one person, not a committee. They may represent the needs of many stakeholders, but those who want to change the Product Backlog do so by convincing the Product Owner. For the Product Owner to succeed, the organisation must respect their decisions.

What it looks like in practice

• Spending real time with customers, users and stakeholders to understand what is valuable.
• Turning a broad vision into a Product Goal the team can work toward. See our glossary entry on the Product Goal.
• Ordering the backlog so the most valuable work comes first, taking risk and dependencies into account.
• Being available to the Developers to clarify items during the Sprint.
• Saying no, or "not now", to requests that do not serve the Product Goal.
• Inspecting the Increment at the Sprint Review and adapting the backlog based on what the team and stakeholders learn.

Common mistakes

• Acting as a proxy who passes stakeholder requests through without making decisions.
• Leaving the backlog as a wish list, unordered and full of vague items.
• Being unavailable to the team, so questions wait days for answers.
• Writing detailed specifications instead of collaborating with Developers on what to build.
• Accepting every request, so the backlog grows faster than the team can deliver.

Skills

Product thinking, prioritisation, stakeholder management, communication, basic data analysis and the confidence to say no with evidence.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organisation. The Scrum Master is also accountable for the Scrum Team's effectiveness. The Scrum Guide describes them as true leaders who serve the Scrum Team and the larger organisation.

The Scrum Master serves:

• The Scrum Team, by coaching team members in self-management and cross-functionality; helping the team focus on creating high-value Increments that meet the Definition of Done; causing the removal of impediments to progress; and ensuring that all Scrum events take place and are positive, productive and kept within the timebox.
• The Product Owner, by helping find techniques for effective Product Goal definition and Product Backlog management; helping the team understand the need for clear and concise backlog items; and facilitating stakeholder collaboration as requested or needed.
• The organisation, by leading, training and coaching it in its Scrum adoption; planning and advising Scrum implementations; helping employees and stakeholders understand an empirical approach to complex work; and removing barriers between stakeholders and Scrum Teams.

What it looks like in practice

• Facilitating events so they produce decisions, not just conversation.
• Asking questions that help the team find its own answers, rather than giving instructions.
• Noticing patterns, such as unfinished work at the end of every Sprint, and helping the team address them.
• Working with managers and other teams to remove impediments the team cannot remove alone.
• Protecting the team from disruption during the Sprint, without becoming a gatekeeper.
• Coaching the organisation on what Scrum needs from it.

Common mistakes

• Acting as a meeting secretary, booking rooms and taking notes, but not coaching.
• Assigning tasks, which undermines self-management.
• Becoming a gatekeeper who controls access to the team.
• Avoiding conflict with stakeholders or managers whose behaviour harms the team.
• Treating the role as administrative rather than as leadership.
• Serving several teams too thinly, so no team gets real coaching.

Skills

Facilitation, coaching, active listening, conflict handling, deep knowledge of Scrum and agile practices, and the ability to influence without authority.

Developers

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The Scrum Guide says Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog.
• Instilling quality by adhering to a Definition of Done.
• Adapting their plan each day toward the Sprint Goal.
• Holding each other accountable as professionals.

"Developers" is not limited to software engineers. It means whoever does the work that creates the Increment: engineers, testers, designers, analysts, writers or others, depending on the product. See the glossary entries on Definition of Done and Sprint Goal.

What it looks like in practice

• Deciding together how to turn backlog items into a done Increment.
• Sharing work across skills rather than waiting for a specialist.
• Raising problems at the Daily Scrum and adjusting the plan.
• Refusing to call work done until it meets the Definition of Done.
• Helping the Product Owner refine backlog items, including estimating them.

Common mistakes

• Waiting for assignments instead of self-managing.
• Separating testing from building, so quality problems surface late.
• Skipping quality to hit dates, which creates technical debt.
• Working in silos, with each person finishing only their own tasks.

Skills

Technical and domain skills, collaboration, a broad willingness to help outside one's specialism, and discipline about quality.

Comparing the three

How the accountabilities work together in Scrum's events

Scrum has five events. Each one brings the accountabilities together.

Product Backlog refinement is an ongoing activity, not an event: the Product Owner and Developers break down and clarify items so they are ready for future Sprints.

Scrum accountabilities and traditional roles

People moving into Scrum often ask how the accountabilities map to roles they know.

• Project manager: there is no project manager in Scrum. Their responsibilities are distributed: the Product Owner owns scope and priorities, the Developers own the plan for the Sprint, and the Scrum Master supports the process. Many project managers become Scrum Masters or Product Owners, but the shift in mindset is large.
• Business analyst: often supports the Product Owner with backlog refinement, or works as a Developer. Some become Product Owners.
• Team lead: in a self-managing team, leadership is shared. A former team lead may become a Scrum Master, or a senior Developer who leads by example.
• Line manager: sits outside the Scrum Team. Managers support teams by removing organisational impediments and developing people.

Signs each accountability is working

Use the table at a Retrospective. Ask each person to mark where the team stands, then discuss the differences. Disagreement is useful: it shows where people experience the team differently, which is usually where the next improvement lies.

Can one person hold two accountabilities?

The Scrum Guide does not explicitly forbid it, but it is widely discouraged, especially combining Product Owner and Scrum Master. The two pull in different directions: the Product Owner pushes for more value; the Scrum Master protects the team's effectiveness and sustainable pace. One person holding both often ends up doing neither well.

A Scrum Master who is also a Developer is more common in small teams, but the Scrum Master work often gets squeezed out by delivery pressure. If you must combine them, agree explicitly how much time goes to each, and review it at Retrospectives.

Choosing a course

• If you will guide a team in Scrum, start with the Certified ScrumMaster path; see our CSM overview and CSM® training.
• If you will set product direction, consider a Product Owner course such as CSPO®.
• For a side-by-side comparison with the Professional Scrum offerings, read CSM vs CSPO vs PSPO.
• Developers benefit from learning the framework even if they do not pursue certification. Many take CSM to understand Scrum properly.
• If your organisation is scaling Scrum across many teams, see our SAFe certification path.

Get free certification pathway advice →

Next step

Tell us which accountability you hold or expect to hold, and we will suggest a learning sequence.

View CSM® Training Schedules →