3.1 Scrum Team Fundamentals

3.1 Scrum Team Fundamentals

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

For PSPO I, you must know the Scrum Team as a single accountability system, not a project org chart. Product Owners who treat Developers as a delivery factory—or who sit above the team as an external customer—fail the empiricism and self-management questions that appear throughout the assessment.

---

Composition: Three Accountabilities, One Team

The 2020 Scrum Guide deliberately uses accountabilities rather than “roles” as the primary framing. Accountabilities describe what must be owned for Scrum to work; they are not job titles or hierarchical ranks.

There is no fourth accountability (no project manager, no business analyst seat, no separate QA manager inside Scrum). Work that those traditional titles used to do is either absorbed by Developers (how the product is built and verified), by the Product Owner (what and why), or by the Scrum Master (how the team uses Scrum effectively).

No sub-teams or hierarchies

Inside one Scrum Team you do not create:

• A “front-end team” and “back-end team” reporting separately
• A hierarchy where a tech lead assigns daily work as a manager of Developers
• A QA sub-team that “accepts” work after Developers finish coding
• A mini Product Owner committee that votes on ordering

Everyone on the Scrum Team is a peer with different accountabilities. The Product Owner does not manage Developers. The Scrum Master does not manage the Product Owner. Developers do not report task status to either as a boss.

---

Size: Typically 10 or Fewer

The Guide states that Scrum Teams are typically 10 or fewer people. Smaller teams communicate with fewer channels, decide faster, and stay agile. Larger groups create coordination cost that undermines empiricism.

Exam implication: If a product needs more capacity than one small team can provide, do not grow one team past effective size. Form multiple Scrum Teams that:

• Share the same Product Goal
• Share the same single Product Backlog
• Share the same single Product Owner
• Each have their own Developers (and typically their own Scrum Master support)
• Integrate into a usable Increment every Sprint under a shared Definition of Done expectation

PSPO I often tests whether you invent “multiple Product Owners per product” to scale. That is incorrect. Scale the teams; keep one PO and one Product Backlog per product.

---

Cross-Functional and Self-Managing

Cross-functional

A cross-functional Scrum Team has all the skills necessary to create value each Sprint. Skills depend on domain (software, hardware, marketing campaign, medical device, etc.), but the principle is constant: the team should not depend on an external specialist team to finish a usable Increment.

Cross-functionality does not mean every person can do every skill. It means the team as a whole can deliver Done work without waiting on a permanent handoff chain outside the team.

Self-managing

Self-managing means the Scrum Team internally decides who does what, when, and how. External managers, stakeholders, and even the Product Owner do not assign daily tasks to individuals.

For Product Owners, this boundary is critical:

If a PO dictates who codes which story or how a feature must be implemented at a micro-task level, the team is no longer self-managing—and empiricism suffers because the people closest to the work are not free to adapt.

---

Focused on the Product Goal; Accountable for the Increment

The Scrum Team is a cohesive unit focused on one objective at a time: the Product Goal. That long-term objective lives as the commitment of the Product Backlog and gives the whole team a shared north star.

Each Sprint, the entire Scrum Team is accountable for creating a valuable, useful Increment that meets the Definition of Done. Accountability is not “Developers deliver and PO accepts at the end.” Value, clarity of backlog items, collaboration on the Sprint Goal, and honest inspection at the Sprint Review are team-level outcomes.

Practical PO behaviors that support team accountability

1. Be available so Developers can clarify Product Backlog items without multi-day delays.
2. Collaborate on the Sprint Goal in Sprint Planning—do not throw a list of stories over the wall.
3. Respect capacity and DoD—do not pressure the team to skip quality for vanity scope.
4. Inspect outcomes with stakeholders at the Sprint Review and adapt the Product Backlog based on evidence.
5. Partner with the Scrum Master when organizational impediments block the team’s ability to deliver Done Increments.

---

Common PSPO I Traps on Team Structure

---

Quick Self-Check

Before moving on, you should be able to state without notes:

• Who is on a Scrum Team, and what is forbidden inside it (sub-teams/hierarchies)
• Why size matters and how multi-team products stay aligned
• What cross-functional and self-managing mean in PO language (WHAT vs HOW)
• That the team’s shared focus is the Product Goal and its Sprint outcome is a valuable usable Increment