A Scrum primer · Part 2 of 5

The Scrum Team

The three accountabilities in a Scrum Team — Product Owner, Scrum Master and Developers — with team size, self-management and the anti-patterns that weaken each one.

One team, three accountabilities

The Scrum Team is the basic unit of Scrum. It has one Product Owner, one Scrum Master and a group of Developers. There are no sub-teams inside it and no internal hierarchy. Everyone on the team works toward the same goal at the same time, which is the Product Goal.

The 2020 Scrum Guide speaks of accountabilities, not roles or job titles. An accountability is a responsibility for an outcome. One person carries each accountability of Product Owner and Scrum Master. The Developers share theirs. A person’s job title outside the team does not change what they are accountable for inside it.

The whole Scrum Team is accountable for one result: a valuable, useful Increment in every Sprint. No single accountability owns that result alone. The Product Owner cannot deliver value without the Developers, and the Developers cannot deliver the right thing without the Product Owner.

Two properties describe a good Scrum Team. It is cross-functional, which means the members together have every skill they need to create value in each Sprint. It is also self-managing, which means the team itself decides who does what, when, and how.

Team size

A Scrum Team is small enough to stay nimble and large enough to finish significant work in a Sprint. The Guide says that a team of ten or fewer people is typical. Smaller teams usually communicate better and get more done per person.

When a team grows too large, the Guide recommends that it reorganize into several cohesive Scrum Teams. All of those teams work on the same product. They share one Product Goal, one Product Backlog and one Product Owner. The product stays whole, even when the people who build it split into separate teams.

The Product Owner

The Product Owner is accountable for the value that the Scrum Team delivers. How they do this varies with the organization and the product. In every case, they are accountable for good management of the Product Backlog. That work includes four things:

Develop the Product Goal and communicate it clearly.
Create Product Backlog items and make their meaning clear.
Put the Product Backlog items in order.
Make sure the Product Backlog is visible, transparent and understood.

The Product Owner can do this work personally or give parts of it to others. In both cases, the Product Owner stays accountable.

The Product Owner is one person, not a committee. They can represent many stakeholders and many needs, but one person decides the order of the backlog. A stakeholder who wants to change the backlog must persuade the Product Owner. The organization must respect the Product Owner’s decisions. Those decisions are visible in the content and order of the Product Backlog, and in the Increment that the team shows at the Sprint Review.

Only the Product Owner can cancel a Sprint. The Guide allows a cancellation when the Sprint Goal becomes obsolete, for example because the market changed or the company changed direction.

The Scrum Master

The Scrum Master is accountable for establishing Scrum as the Scrum Guide defines it. They help everyone in the team and in the wider organization understand the theory and the practice. The Scrum Master is also accountable for the effectiveness of the Scrum Team. They make the team’s practices better within the Scrum framework.

The Guide describes the Scrum Master as a true leader who serves. That service goes in three directions.

To the Scrum Team: The Scrum Master coaches the team in self-management and cross-functionality. They help the team focus on high-value Increments that meet the Definition of Done. They cause impediments to the team’s progress to be removed. They make sure that every Scrum event takes place, stays positive and productive, and stays within its timebox.
To the Product Owner: The Scrum Master helps the Product Owner find techniques to define the Product Goal and to manage the Product Backlog. They help the team understand why backlog items must be clear and concise. They help establish empirical product planning, and they help the team work with stakeholders when someone asks for it or when the team needs it.
To the organization: The Scrum Master leads, trains and coaches the organization in its adoption of Scrum. They plan and advise Scrum implementations. They help employees and stakeholders understand an empirical approach to complex work. They remove barriers between stakeholders and Scrum Teams.

The Guide’s wording here is careful. The Scrum Master causes impediments to be removed, but does not have to remove every obstacle personally. Often the best result is a team that removes its own impediments, with the Scrum Master working on the ones that sit outside the team.

The Developers

The Developers are the people who create any part of a usable Increment in each Sprint. The word “Developers” does not mean programmers only. It includes anybody who does the work: designers, testers, analysts, writers, engineers. The skills they need depend on the product.

The Developers are always accountable for four things:

Create a plan for the Sprint. This plan is the Sprint Backlog.
Build quality into the work by following the Definition of Done.
Adapt their plan every day toward the Sprint Goal.
Hold each other accountable as professionals.

The Developers also own the question of how to do the work. In Sprint Planning, the Product Owner helps them understand what is valuable. The Developers then decide how to turn the selected items into a Done Increment. Nobody outside the Developers tells them how to do that.

What self-management means

Self-management does not mean “no management” or “no leadership”. It means that the team makes the decisions about its own work, inside clear limits. The Product Goal, the Sprint Goal and the Definition of Done set those limits. Inside them, the team chooses its approach, divides the work, and changes its plan when it learns something new.

This matters because of adaptation, the third pillar of Scrum. A team that must ask for permission to change its plan adapts slowly. A team that can change its plan the same day uses what it learns while that knowledge is still useful.

Stakeholders

Stakeholders are not members of the Scrum Team, but Scrum depends on them. They are the customers, users, sponsors and other people with an interest in the product. The Product Owner represents their needs in the Product Backlog. At the Sprint Review, the Scrum Team shows them the results of the Sprint and asks for their input. Without real stakeholder feedback, the Sprint Review has no one to inspect the product with.

Common anti-patterns

The Scrum Guide does not list anti-patterns. The list below comes from common experience with Scrum teams. Each item weakens one accountability, and with it, the empiricism that Scrum depends on.

Practical advice, not a rule of the Scrum Guide

The proxy Product Owner: The named Product Owner has no real authority. Every decision goes back to a manager or a committee. The team waits, and the backlog order changes with whoever spoke last.
The backlog clerk: The Product Owner writes tickets on request and does not own the order or the Product Goal. The backlog becomes a list of wishes with no strategy.
The absent Product Owner: The Product Owner is too busy to answer questions during the Sprint or to attend the Sprint Review. The Developers guess, and the Increment drifts from what users need.
The Scrum Master as secretary: The Scrum Master books rooms, takes notes and updates the tool, and does nothing else. Nobody coaches the team, and nobody works on the impediments outside the team.
The Scrum Master as manager: The Scrum Master assigns tasks and reports on individuals. Team members stop raising problems openly, because the person who hears them also judges them.
Teams split by skill: Separate teams for design, development and testing hand work to each other. No team can finish an Increment alone, so no team is accountable for one.
Part-time members everywhere: A person sits on four teams at twenty-five percent each. They attend every event and finish little. Focus, one of the five Scrum values, is lost.
A team that never gets smaller: New people join, and nobody splits the team. Every event takes longer, and the Daily Scrum becomes a status report to a crowd.

This primer follows the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland and explains it in our own words. Read the Guide itself at scrumguides.org. The Scrum Guide is available under the Creative Commons Attribution-ShareAlike 4.0 license. Scrum.org and Scrum Inc. did not write or review this page.