PSK-I Part B: The Scrum Team

This is Part B of the PSK-I Exam Prep series. It covers the Scrum Team structure and each of the three accountabilities in depth.

B1. The Scrum Team Structure

What it is. A single, cohesive unit of professionals — 10 or fewer, with no sub-teams and no hierarchies — focused on one Product Goal, comprising three accountabilities: Product Owner, Scrum Master, Developers.

Why it matters. The 2020 Guide removed the old “team within a team” model (a separate Development Team vs PO) to eliminate proxy dynamics and “us vs them” tensions. There is now one Scrum Team with one objective and three sets of accountabilities.

Two key properties.

Cross-functional: the team as a whole collectively has all the skills needed to create value each Sprint. This does not mean everyone can do everything — specialists are fine, as long as the team together has full capability.
Self-managing: the team decides who does what, when, and how. The 2020 Guide widened the older definition (“who & how”) to explicitly add what — a meaningful change that exam questions probe.

Scaling. If the team grows too large, split into multiple cohesive teams that share one Product Goal, one Product Backlog, and one Product Owner. Multiple teams on one product also share the same Definition of Done.

Misconception to avoid. “Each scaled team gets its own Product Goal and Product Owner.” No — they share.

Worked example. An “agile team” of 18 keeps missing its Sprint Goal and drowning in coordination. The right move: reorganise into two teams of ≤10 sharing the same Product Goal, Product Backlog, and Product Owner — not split the product.

How questions come.

“How many accountabilities does a Scrum Team have?” → three. Trap: “five, including stakeholders.”
“A Scrum Team has grown to 18 — best guidance?” → split into teams sharing Goal/Backlog/PO.
“Cross-functional means…” → the team collectively has all needed skills (not “everyone can do every task”).
“A project manager assigns each Developer’s tasks.” → violates self-management.

B2. Product Owner

What they are. The single person accountable for maximising the value of the product and for effective Product Backlog management.

Accountabilities (precise list).

Developing and explicitly communicating the Product Goal
Creating and clearly communicating Product Backlog items
Ordering the Product Backlog
Ensuring the backlog is transparent, visible, and understood

The PO may delegate this work but remains accountable. For the PO to succeed, the whole organisation must respect their decisions.

Key nuances.

One person, not a committee. The PO may represent many stakeholders, but a committee cannot hold the accountability.
Others can influence ordering; the PO decides.
Only the Product Owner can cancel a Sprint — and only when the Sprint Goal becomes obsolete.

Misconception to avoid. “The PO writes every backlog item personally.” They can delegate; accountability stays with the PO.

Worked example. Three department managers each insist their feature is top priority. They can lobby, but the Product Owner sets the single order based on value. “The order is decided by the steering committee” is wrong — that contradicts the one-person accountability.

How questions come.

“Developers disagree with the backlog order — who decides?” → Product Owner.
“Conflicting priorities from many managers — who reconciles?” → Product Owner (not a committee).
“Who can cancel a Sprint?” → only the Product Owner, when the Sprint Goal is obsolete.

B3. Scrum Master

What they are. A true leader who serves the Scrum Team and the larger organisation; accountable for establishing Scrum and for the Scrum Team’s effectiveness.

The three “serves.”

Serves the Scrum Team:

Coaches self-management and cross-functionality
Helps the team focus on high-value Increments meeting the DoD
Removes impediments
Keeps events positive, productive, and within timebox

Serves the Product Owner:

Helps with Product Goal definition and Product Backlog techniques
Fosters stakeholder collaboration

Serves the organisation:

Leads, trains, and coaches Scrum adoption
Helps people understand empirical, complex work
Removes barriers between stakeholders and teams

Key nuances.

The 2020 Guide reframed “servant-leader” as “true leader who serves” — leadership and service, not a passive helper.
The Guide does not require the SM to be full-time or dedicated to a single team.
The SM enables effectiveness but does not manage or assign work.

Misconception to avoid. “The SM runs the Daily Scrum / assigns tasks / reports status.” All of these undercut self-management.

Worked example. A new Scrum Master is asked by a manager to hand out daily tasks and report each Developer’s progress. The right response: decline and coach self-management — the Developers decide who does what; the Daily Scrum is theirs.

How questions come.

“Who is accountable for the Scrum Team’s effectiveness?” → Scrum Master.
“A service the SM provides to the organisation?” → leading/coaching Scrum adoption; removing barriers between stakeholders and teams.
“SM asked to assign tasks?” → decline; team self-manages.
Trap: “SM must be full-time on one team,” “SM directs the Developers.”

B4. Developers

What they are. The team members committed to creating any aspect of a usable Increment each Sprint.

Always accountable for:

Creating the Sprint Backlog plan
Instilling quality by adhering to the Definition of Done
Adapting their plan each day toward the Sprint Goal
Holding each other accountable as professionals

Key nuances.

“Developers” is not “programmers” — it’s whoever does the work to build the Increment: designers, testers, writers, analysts, etc.
Developers decide how much to take into a Sprint and own the Sprint Backlog. The PO cannot force a volume of work on them.

Misconception to avoid. “The PO sets how much work the Developers take on.” No — the Developers judge feasibility.

Worked example. During Planning the PO wants 14 items; the Developers, using historical throughput, judge ~9 realistic. They take 9. The PO can’t force more; scope is negotiated, not imposed.

How questions come.

“Who selects how much work enters the Sprint?” → Developers.
“Which accountability belongs to the Developers, not the PO?” → instilling quality via the DoD.
“Who owns the Sprint Backlog?” → Developers.

Next: Part C — The Scrum Events — Sprint, Planning, Daily Scrum, Review, and Retrospective, with every timebox you need to know cold.