3.1 The Scrum Team

The Fundamental Unit of Scrum

The 2020 Scrum Guide calls the Scrum Team the fundamental unit of Scrum. This single phrase carries enormous weight on the PSM I exam, because most accountability questions are really testing whether you have internalized one idea: Scrum has exactly one team, not a manager who hands work to a separate "development team," and not layers of leads and sub-leads. Get this mental model right and a large block of the exam becomes straightforward.

A Scrum Team consists of one Scrum Master, one Product Owner, and Developers. The Guide is explicit that within a Scrum Team there are no sub-teams and no hierarchies. There is no separate QA team nested inside it, no "tech lead" who outranks the other Developers, and no management layer between the Product Owner and the people doing the work. It is a cohesive unit of professionals focused on one objective at a time — the Product Goal.

The Scrum Team is also small. The Guide describes it as small enough to remain nimble and large enough to complete significant work within a Sprint. The single number it offers is typically 10 or fewer people, with the plain rationale that smaller teams communicate better and are more productive. Note what the Guide deliberately leaves out: there is no minimum size, no "7 plus or minus 2" range (that older heuristic was removed in 2020), and no rule excluding the Scrum Master or Product Owner from the headcount. The Scrum Master and Product Owner are full members of the one Scrum Team, not outside overseers.

Cross-Functional and Self-Managing

Two properties define how a Scrum Team operates, and PSM I returns to both repeatedly:

• Cross-functional — collectively, the members have all the skills necessary to create value each Sprint. The team does not have to wait on a separate group outside it to get a usable Increment done. Cross-functionality is a property of the team as a whole, not of each individual; no single person must hold every skill.
• Self-managing — the team internally decides who does the work, what it works on, when, and how. This is a 2020 change in language from the older term "self-organizing," and it broadens the autonomy: self-management covers not only how work gets organized but the choice of what to work on within the Sprint and who does it. No one from outside the Scrum Team tells the Developers how to turn Product Backlog items into Increments.

The Scrum Guide also makes the Scrum Team responsible for all product-related activities — stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else the product requires. They are structured and empowered by the organization to manage their own work.

Collective Accountability and Scaling

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. This is a collective accountability — you cannot point to one role and say "that person is to blame for a bad Increment." Within that collective accountability, Scrum then defines three specific accountabilities: Developers, Product Owner, and Scrum Master. These are accountabilities, not job titles or hierarchical roles — a frequent and deliberate distinction tested on PSM I (the 2020 Guide intentionally replaced the word "roles" with "accountabilities").

When a Scrum Team becomes too large, the Guide's prescribed response is to reorganize into multiple cohesive Scrum Teams. Crucially, those teams continue to share the same Product Goal, the same Product Backlog, and the same Product Owner. Splitting the work across teams does not split ownership of the product. A trap answer gives each new team its own Product Owner and separate backlog — that fragments the product direction Scrum is designed to keep coherent.

Common PSM I traps for this section

• "The Scrum Team contains a Development Team that reports to the Scrum Master" — false; the separate Development Team concept was removed in 2020 and the Scrum Master is not a manager.
• "A Scrum Team must have 3 to 9 Developers" — false; that range was removed. Only typically 10 or fewer (whole team) remains.
• "The Scrum Master and Product Owner are not counted in team size" — false; they are members of the one team.
• "When the team grows, split into independent teams each with its own Product Owner" — false; the Product Owner, Product Goal, and Product Backlog stay shared.

Why 'One Team' Matters for Empiricism

The Scrum Team's single, flat structure is not an arbitrary preference — it directly serves Scrum's empirical foundation. Empiricism rests on three pillars: transparency, inspection, and adaptation. A team with hidden sub-teams, hand-offs, and a management layer leaks transparency: work passes between groups, accountability blurs, and the people inspecting an Increment are not the people who can adapt the plan. By keeping one cohesive team that is cross-functional and self-managing, Scrum ensures the same group that builds the Increment also inspects and adapts — closing the empirical loop inside one Sprint.

The same structure protects the five Scrum Values — commitment, focus, openness, respect, and courage. A self-managing team focused on a single Product Goal can commit to a Sprint Goal and stay focused; openness and respect are far easier among peers than across a hierarchy.

Members vs. accountabilities

A frequent point of confusion: every member of the Scrum Team holds one of the three accountabilities, but the accountabilities are not exclusive people slots in a rigid sense. There is exactly one Product Owner and exactly one Scrum Master, and everyone else committed to building the Increment is a Developer. One person may, in some organizations, hold more than one accountability, but the Scrum Guide cautions that combining accountabilities can create conflicts (for example, a Product Owner who is also a Developer may struggle to balance value decisions against delivery).

For PSM I, hold the defaults: one Product Owner, one Scrum Master, and the Developers — all on one team, with no internal hierarchy.