The Scrum Team

One small team

The Scrum Team is the fundamental unit of Scrum: one Scrum Master, one Product Owner and the Developers. The Scrum Guide is explicit that within a Scrum Team "there are no sub-teams or hierarchies". It is one group of professionals focused on one objective at a time, the Product Goal.

The team is "typically 10 or fewer people": small enough to stay nimble, large enough to finish significant work in a Sprint. The reason is communication. Every person you add adds lines of communication with everyone else, and large groups split into cliques and hand-offs. When a team grows too large, the guide advises reorganizing into several cohesive Scrum Teams that work on the same product and therefore share the same Product Goal, Product Backlog and Product Owner. How several teams coordinate is covered in Scaling Agile.

The Scrum Team is responsible for everything related to its product: working with stakeholders, verification, maintenance, operation, experimentation, research and development. And the entire team is accountable for creating a valuable, useful Increment every Sprint, not one person or one accountability.

At Kestrel Energy, the Portal team builds and runs the customer portal and app. Isabel Santos is the Product Owner, Lars de Boer the Scrum Master, and Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters are the Developers. That is seven people, well within the guideline.

Cross-functional

A cross-functional team has all the skills needed to create value every Sprint, without waiting for other departments. In the Portal team, Ravi is strong in back-end code, Sofia in the app, Priya in testing and accessibility, Bram in databases and Kwame in the billing integration. Together they can take an item from idea to a usable, released Increment.

Cross-functional describes the team, not each person. Nobody has to be able to do everything. But skills should spread over time, so that one person's holiday does not stop the Sprint: when Priya is away, Sofia and Ravi can still run the accessibility checks.

Self-managing

A self-managing team decides internally who does what, when and how. The 2020 guide chose "self-managing" over the older "self-organizing" on purpose: the self-management now belongs to the whole Scrum Team, and the authors describe it as deciding who, how and also what to work on. Nobody outside the team assigns tasks to individual Developers during the Sprint.

Self-managing does not mean unmanaged. The organization still sets the boundaries: the product the team works on, the budget, the standards such as an organizational Definition of Done, and the Product Owner's ordering of the Product Backlog. Within those boundaries, the team manages its own work. In the guide's words, it is "structured and empowered by the organization to manage their own work".

Accountabilities, not roles

The Scrum Guide 2020 defines three accountabilities within the Scrum Team: the Developers, the Product Owner and the Scrum Master. An accountability is the obligation to answer for an outcome. Older editions spoke of "roles"; the change of word signals that Scrum is about who is answerable for what, not about job titles. Your job title might be "senior software engineer", "network engineer" or "test analyst"; in the Scrum Team, your accountability is Developer.

Accountable is not the same as doing all the work. The Product Owner may delegate work on the Product Backlog to others but remains accountable for it. The guide also expects that a Product Owner or Scrum Master who actively works on items in the Sprint Backlog takes part in the Daily Scrum as a Developer.

Developers

Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. The word does not mean "programmers". The guide uses it "not to exclude, but to simplify": testers, designers, analysts, database administrators, writers and operations engineers who create the Increment are all Developers. How a team without a separate tester shares the testing work is described as the whole-team approach.

Whatever their skills, the Developers are always accountable for:

• Creating the plan for the Sprint, the Sprint Backlog. Nobody else tells them how to turn Product Backlog items into an Increment.
• Building in quality by following the Definition of Done. Quality is not something a separate team adds afterward.
• Adapting their plan every day toward the Sprint Goal, in the Daily Scrum and in between.
• Holding each other accountable as professionals. Peers, not a manager, address it when someone's work falls short.

The Product Owner

The Product Owner is accountable for maximizing the value of the product that results from the Scrum Team's work. The guide leaves open how this is done, because it varies widely between organizations. The Product Owner is also accountable for effective Product Backlog management, which in our own words covers four things:

• developing the Product Goal and communicating it explicitly;
• creating Product Backlog items and communicating them clearly;
• ordering the Product Backlog items;
• making sure the Product Backlog is transparent, visible and understood.

Three rules from the guide matter in practice:

• One person, not a committee. The Product Owner may represent many stakeholders, but one person decides. Anyone who wants to change the Product Backlog does so by convincing the Product Owner.
• Delegation is allowed; accountability stays. Isabel can ask Ravi to write the technical items or Kwame to describe the billing changes, but she remains accountable for the Product Backlog.
• The organization must respect the decisions. Those decisions are visible in the content and order of the Product Backlog and in the Increment shown at the Sprint Review. A Product Owner who is overruled behind the scenes cannot maximize value.

Day-to-day practice, such as working with stakeholders, saying no and measuring value, is on The Product Owner in Practice.

The Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, by helping everyone in the team and the organization understand Scrum theory and practice. The Scrum Master is also accountable for the Scrum Team's effectiveness, by enabling the team to improve its practices within the Scrum framework. The guide describes Scrum Masters as "true leaders who serve the Scrum Team and the larger organization".

The guide lists three groups the Scrum Master serves. In our own words:

Note the wording "causing the removal of impediments". Lars does not have to remove every impediment himself; often the best help is making sure the right person removes it, or coaching the team to remove it on their own. More on this in The Scrum Master in Practice.

Stakeholders and managers

Everyone outside the Scrum Team who has an interest in the product is a stakeholder: customers, users, the service desk, the billing department, legal, and managers. Stakeholders are not part of the Scrum Team, but Scrum expects them to be involved: they attend the Sprint Review, they influence the Product Backlog through the Product Owner, and they can be invited to Sprint Planning to give advice.

Managers do not appear in the Scrum Guide at all. That does not make them unnecessary; their work moves. Instead of assigning tasks, a manager in a Scrum organization typically creates the conditions for teams to succeed: hiring, budgets, removing organizational obstacles, career development and setting clear goals. A line manager who walks up to Bram with "just do this quickly" is bypassing the Product Owner and disrupting the Sprint.

Who owns what

Common confusions

• The Product Owner is not a project manager. The Product Owner decides what is most valuable and in which order. They do not assign tasks, track hours or tell the Developers how to build. Scrum has no project manager accountability; the responsibilities of a traditional project manager are spread over the three accountabilities.
• The Scrum Master is not a team lead. Lars has no authority over the Developers' work and does not hand out tasks. His leadership is about the team's effectiveness and the way Scrum is used, not about the content of the work.
• "QA", "architect" and "business analyst" are not Scrum accountabilities. People with those skills are welcome in the team, but in Scrum they are all Developers, and quality is everyone's job through the Definition of Done.
• No committee of Product Owners. A "product owner board" in which three managers decide together is not a Product Owner. They can all be stakeholders who try to convince the one Product Owner.