The Scrum Team and its accountabilities

One team, and nothing inside it

A Scrum Team is one team of people — a Product Owner, Developers and a Scrum Master — with no sub-teams and no hierarchies inside it. It is cross-functional, meaning it holds every skill needed to create value each Sprint, and self-managing, meaning it decides internally who does what, when and how. Typically it is ten people or fewer, and that figure is guidance about staying nimble rather than a limit anybody enforces.

That structure answers a whole family of questions before they are asked. Appointing a team lead inside the Scrum Team to coordinate eighteen people is wrong because it reintroduces exactly the layer the framework removed in order to make self-management possible. A separate testing group, an architecture authority that signs designs off, and a component team are the same wrong answer with different job titles.

When a team genuinely has outgrown itself — eighteen people, a Daily Scrum that always overruns, nobody holding a complete picture — Scrum does not add structure inside it. It reorganises into several cohesive Scrum Teams, and those teams share the same Product Goal, the same Product Backlog and the same Product Owner. The sharing is the tested half: giving each new team its own backlog is the split that feels most natural and does the most damage, because two orderings of value for one product means nobody can answer what the product should do next.

The Product Owner is one person, and that is load-bearing

The Product Owner is accountable for maximising the value of the product, and the work that accountability shows up as is all about the Product Backlog: developing and explicitly communicating the Product Goal, creating and clearly communicating the items, ordering them, and making sure the backlog is transparent, visible and understood. All of that work may be shared out — and the Guide closes the door the exam likes to open in the same breath: "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable."

The Product Owner is one person rather than a committee, which is what keeps the ordering answerable to anyone who asks about it. It is also why the legitimate route for a stakeholder who dislikes where their request sits is persuasion: they can try to convince the Product Owner, and that is the entire mechanism. A senior stakeholder walking up to two Developers mid-Sprint and asking them to slot something into the next Sprint is not using it.

The requirement candidates most often see inverted runs the other way round. For a Product Owner to succeed, the whole organisation has to respect their decisions — that is stated as an obligation on the organisation, not a courtesy from it. Seniority does not settle an ordering dispute, and an option in which the Scrum Team defers to the hierarchy has the obligation pointing backwards.

The Developers own how, and their own quality bar

Scrum states a short list the Developers are always accountable for, whatever the domain of work: creating the Sprint Backlog as the plan for the Sprint, instilling quality by adhering to the Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals. Every entry is about how they govern their own work.

That shape is the fastest way to answer a question about the list, including one that offers an entry nobody memorised. Anything on it concerns the plan, the quality bar, the daily adjustment or the team's own conduct. Anything about what the product should do next — ordering the backlog, deciding what is most valuable, choosing whether something is released — belongs to the Product Owner, and an option that hands one of those to the Developers is testing this boundary rather than the list.

A Scrum Master serves three parties and manages none

The Scrum Master is accountable for establishing Scrum and for the Scrum Team's effectiveness, and the service is spelled out as three lists: to the Scrum Team, to the Product Owner and to the organisation. The third is the one candidates forget and the one scenarios are built from — leading, training and coaching the organisation in its adoption, helping employees and stakeholders enact an empirical approach to complex work, and removing barriers between stakeholders and Scrum Teams.

Nothing on any of the three lists is managing people, allocating work or reporting on individuals. So when a department head asks for a weekly report of which Developer completed which task and wants the Scrum Master to chase whoever is behind, neither complying nor simply refusing is the answer. The request almost always hides a real need for predictability, and Scrum answers that need with a Done Increment every Sprint. Teaching that is the accountability; supplying the report is its opposite, and having the Developers write the report themselves changes nothing — the problem is individual accountability for tasks inside a team Scrum makes accountable together.

Note also what a Scrum Master does not get authority over. They ensure the events happen, are productive and stay inside their timebox. They do not decide what the product does next, they cannot cancel a Sprint, and they have no approval role over how a Product Owner chooses to organise their own work.