Who's Who on an Agile Team: Product Owner, Scrum Master and More

One of the most confusing parts of joining an agile team is figuring out who does what. Someone is called the Product Owner, someone else is the Scrum Master, everyone else seems to be a "developer" even if they never write code, and there is frequent talk about "stakeholders."

Most agile teams that use these titles take them from Scrum, and the official source is the Scrum Guide, written by Scrum's creators Ken Schwaber and Jeff Sutherland and last revised in November 2020. This guide walks through each part of the team as the Scrum Guide describes it, then covers the people around the team, with practical tips for working with each.

First, a mindset shift: accountabilities, not job titles

The Scrum Guide does not describe a hierarchy. It says a Scrum Team "consists of one Scrum Master, one Product Owner, and Developers," and that "Within a Scrum Team, there are no sub-teams or hierarchies."

It also says the "entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint" and then defines three specific accountabilities within the team: the Developers, the Product Owner and the Scrum Master. Think of these as areas of responsibility rather than ranks.

A few more team-level facts from the guide are useful for beginners:

• Teams are cross-functional, meaning members together have all the skills needed to create value each Sprint.
• Teams are self-managing, meaning they "internally decide who does what, when, and how."
• A Scrum Team is "typically 10 or fewer people." If a team grows too large, the guide suggests splitting into multiple teams focused on the same product, sharing one Product Goal, one Product Backlog and one Product Owner.

The Product Owner: the "what" and the "why"

The Product Owner is "accountable for maximizing the value of the product resulting from the work of the Scrum Team." In practice, that mostly happens through the Product Backlog, the ordered list of work. According to the Scrum Guide, the Product Owner is accountable for:

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

The Product Owner may delegate some of that work, but remains accountable. Two lines from the guide are especially worth knowing. First, "The Product Owner is one person, not a committee." Second, "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner." The guide adds that for Product Owners to succeed, "the entire organization must respect their decisions."

Working with a Product Owner: bring requests and ideas to them rather than directly to individual team members, ask how a request connects to the Product Goal, and expect that "not now" is a legitimate answer when other work is more valuable.

The Scrum Master: how well the team works

The Scrum Master is accountable for "establishing Scrum as defined in the Scrum Guide" and for "the Scrum Team's effectiveness." The guide calls Scrum Masters "true leaders who serve the Scrum Team and the larger organization."

That service runs in three directions:

• For the team: coaching self-management and cross-functionality, helping the team focus on high-value Increments that meet the Definition of Done, "causing the removal of impediments," and making sure events happen, are productive and stay within their timeboxes.
• For the Product Owner: helping find techniques for defining the Product Goal and managing the backlog, and facilitating stakeholder collaboration.
• For the organization: leading, training and coaching Scrum adoption, and "removing barriers between stakeholders and Scrum Teams."

A common beginner misunderstanding is that the Scrum Master is the team's manager or the person who assigns tasks. Because the team is self-managing and decides "who does what, when, and how," that is not the role the guide describes. Nor is the Scrum Master just the meeting scheduler. If something is blocking your work that you cannot fix yourself, the Scrum Master is a good person to tell.

Developers: the people who build it

In Scrum, "Developers" means anyone on the team "committed to creating any aspect of a usable Increment each Sprint," whether that is coding, design, writing, testing or analysis. The guide explains: "We use the word 'developers' in Scrum not to exclude, but to simplify."

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

The guide gives Developers real authority over their work. During Sprint Planning, how the selected work gets done "is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value." Developers are also responsible for sizing backlog items, while the Product Owner may help them understand trade-offs.

Stakeholders: everyone with a stake

Stakeholders are not one of Scrum's three accountabilities, but they appear throughout the guide. The Product Owner "may represent the needs of many stakeholders in the Product Backlog." The Sprint Goal communicates why the Sprint is valuable to stakeholders. And at the Sprint Review, "The Scrum Team presents the results of their work to key stakeholders."

The Kanban Guide offers a handy general definition: a stakeholder is "An entity, individual, or group responsible for, interested in, or affected by" the work. That can include customers, users, sponsors, other departments and leadership.

If you are a stakeholder, the most useful things you can do are attend Sprint Reviews and give honest feedback on what you see, route new requests through the Product Owner, and remember that the review is meant to be a working session, not just a presentation.

Where do managers fit?

The Scrum Guide does not define a manager accountability, which leads some beginners to assume agile teams have no managers. Agile Alliance's introductory guide addresses this directly: "There still is a place for managers." It describes managers making sure team members have or obtain the right skills, providing an environment that allows the team to succeed, and stepping in "when the teams try but are unable to resolve issues."

Putting it together: a hypothetical week

Imagine a seven-person team building an online registration system for a city parks department. The recreation director, a stakeholder, asks for a waitlist feature. She brings it to the Product Owner, who adds it to the Product Backlog and orders it near the top because full classes are a frequent complaint.

At Sprint Planning, the Developers pull the waitlist item into the Sprint and decide among themselves how to build it. Midweek, they discover they need access to the payment system, which another department controls. The Scrum Master works with that department to clear the impediment. At the Sprint Review, the director tries the waitlist and suggests an email notice when a spot opens. The Product Owner adds that as a new backlog item.

Nobody gave orders down a chain; each accountability did its part.

Key takeaways

• A Scrum Team has one Product Owner, one Scrum Master and Developers, with no sub-teams or hierarchies.
• The Product Owner is one person accountable for value and the order of the Product Backlog.
• The Scrum Master is accountable for the team's effectiveness and for removing impediments, not for assigning tasks.
• "Developers" includes everyone who helps create the Increment, and they decide how the work gets done.
• Stakeholders shape the product through the Product Owner and the Sprint Review; managers support the environment.

Sources

• Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
• Agile Alliance, Agile 101: What is Agile?