The Scrum Team: three accountabilities and no hierarchy

Picture a team where the designer waits for the architect, who waits for the manager, who waits for a steering group. Work moves through four hand-offs, and each one is a place for it to sit. A Scrum Team is built to remove those queues, and nearly every rule about it follows from that aim.

What the Scrum Guide says

The Guide opens with a short description. The fundamental unit of Scrum is a small team of people. The team consists of one Scrum Master, one Product Owner and Developers. Within it there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Two further words do much of the work in that description.

Cross-functional. The members have all the skills necessary to create value each Sprint. If the team needs a database specialist, a tester and someone who can write the interface, those people are on the team, not on a list of people it has to ask.

Self-managing. The team decides internally who does what, when and how. Nobody outside it assigns the tasks. This is why the Guide says the Scrum Master serves the team by coaching it in self-management, and does not direct it.

Small, on purpose

The Guide says the team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically ten or fewer people. It adds that smaller teams generally communicate better and are more productive.

The SBOK® Guide gives a more specific band: its optimum size is six to ten members, large enough to hold the skills and small enough to collaborate easily. It also names the downside of the lower end, which is that a small team feels the loss of one person more sharply, even for a short time. Illness, a holiday or a resignation takes a visible share of the capacity, and it suggests back-up people and some skill overlap as the remedy.

When a team grows beyond what it can sensibly coordinate, the Guide's advice is to reorganise into several cohesive Scrum Teams focused on the same product, sharing one Product Goal, one Product Backlog and one Product Owner. The answer to a bigger product is more teams working from the same backlog, not a bigger team.

Three accountabilities

The Guide defines three specific accountabilities within the team, and it is careful with the word. They are not job titles, and one person can be accountable for something while others do the work.

• The Developers are committed to creating any aspect of a usable Increment each Sprint. They create the plan for the Sprint, instil quality through the Definition of Done, adapt their plan each day toward the Sprint Goal, and hold each other accountable as professionals. See Developers on a Scrum team.
• The Product Owner is accountable for maximising the value of the product. See the Product Owner role.
• The Scrum Master is accountable for establishing Scrum and for the team's effectiveness. See how that differs from a project manager.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. That sentence is easy to skim past, and it matters. The Product Owner is not accountable for the product while the Developers are accountable for the code. Everyone is accountable for the outcome, and the three accountabilities describe where each person's particular responsibility sits.

What the team is responsible for

The Guide gives the Scrum Team responsibility for all product-related activities: stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else the product needs. In practice that includes the work that other models separate into testing teams, operations teams and support teams. A Scrum Team is structured and empowered by the organisation to manage its own work, and it works in Sprints at a sustainable pace to improve its focus and consistency.

The Agile Manifesto states a principle that sits behind this: the best architectures, requirements and designs emerge from self-organising teams, and projects are built around motivated individuals who are given the environment and support they need and trusted to get the job done.

A common confusion: two meanings of "Scrum Team"

The SBOK® Guide uses the term differently, and anyone moving between the two sources will trip on it. In the SBOK, the core roles are the Product Owner, the Scrum Master and the Scrum Team, and together they form the Scrum Core Team. Its "Scrum Team" is only the group that understands the Product Owner's requirements and creates the deliverables. That is what the Scrum Guide calls the Developers.

So the same sentence can be correct in both books and mean different things. "The Scrum Team estimates the stories" is a statement about the Developers in the SBOK, and a statement about everyone in the Guide. When you read an SBOK process description, replace "Scrum Team" with "Developers" and it will line up with the Guide.

The SBOK also names roles outside the core team: business stakeholders, an optional Scrum Guidance Body of experts or documents, and vendors. The Guide does not define these as Scrum roles, although stakeholders appear throughout it.

Common mistakes

• Treating the Product Owner and Scrum Master as extra to the team. They are members, not visitors.
• Creating sub-teams. A "front-end team" and a "back-end team" inside one Scrum Team recreate the hand-off the framework is trying to remove.
• Staffing the team with part-timers across many products. The Guide asks for a team focused on one objective at a time. Constantly switching context erodes the focus that Sprints are meant to protect.
• Giving the team a manager who assigns work. If someone outside decides who does what, the team is not self-managing, whatever it is called.
• Letting a "senior" role override the team. Within the team there is no hierarchy. Seniority of experience is real, but it does not become authority over how the work is done.

How to practise it

A team is easiest to understand from inside one. In the simulator you take one role on a six-person team, and named AI teammates play the other five. Forming the team and agreeing how it will work together is the third step of the first phase.