Scrum Master Accountabilities: 2020 Guide Explained for PSM I & CSM

If you're preparing for the PSM I or CSM exam, there's one conceptual shift that trips up more candidates than almost any other: the move from roles to accountabilities introduced in the 2020 Scrum Guide. It sounds like a semantic tweak, but the implications run deep — and exam questions are specifically designed to test whether you understand the difference or are just memorizing vocabulary.

This isn't about cramming definitions. The 2020 Scrum Guide update reflects a deliberate philosophical evolution in how Scrum thinks about responsibility, ownership, and team dynamics. When you genuinely understand why these changes were made, the exam questions become far more intuitive — and more importantly, you become a better practitioner.

Whether you're a developer stepping into Scrum Master training for the first time or a seasoned project manager pursuing certification, this article walks you through the accountability model in precise, practical terms. Expect real scenarios, exam-specific mindset tips, and the kind of nuanced explanation that separates candidates who pass from those who nearly pass.

---

From Roles to Accountabilities: What Changed in the 2020 Scrum Guide?

The 2017 Scrum Guide described three roles within the Scrum Team: the Scrum Master, the Product Owner, and the Development Team. The 2020 update retired that language entirely. You'll no longer find the word "role" used in the same structural sense. Instead, the guide uses the term accountabilities to describe what each member of the Scrum Team is answerable for.

Why does this matter? Because the word "role" implies a job title, a position, a hat you wear. "Accountability," on the other hand, implies ownership — it means you are answerable for an outcome, not just for performing a set of tasks. That's a much heavier concept, and it changes how you should interpret exam scenarios.

The 2020 guide also dissolved the concept of the "Development Team" as a separate entity. Instead, it introduced Developers — a simple but powerful change. Anyone on the Scrum Team who works toward creating usable Increments is a Developer, including people who do testing, design, architecture, or analysis. The Product Owner and Scrum Master are also considered part of the Scrum Team, and they can take on Developer work if that's what the team needs. This flattening was intentional: Scrum no longer wants you thinking about sub-teams within the team.

What Stayed the Same (And Why That Matters Too)

The three accountabilities — Scrum Master, Product Owner, Developers — map closely to the old three roles. The events, artifacts, and commitments remain largely intact. What changed is the framing: every accountability now carries an explicit ownership statement tied to the Scrum Team's purpose of delivering value. This is important on the exam because questions may present a scenario where someone is "responsible" for a task and ask who is accountable — and those may not be the same person.

---

Accountability vs. Responsibility: The Critical Distinction for the Exam

This is probably the single most nuanced concept tested across both PSM I and CSM exams. Let's be precise: accountability and responsibility are not synonyms in the Scrum context.

Responsibility refers to doing work. It can be shared, delegated, distributed across multiple people. A Developer can be responsible for writing unit tests. The Scrum Master can be responsible for facilitating the Daily Scrum if the team genuinely needs that support.

Accountability refers to ownership of outcomes. It cannot be shared in the same way. If the Product Backlog is not ordered, the Product Owner is accountable — even if they delegated the actual ordering task to someone else. If the Scrum Team isn't practicing Scrum effectively, the Scrum Master is accountable — even if every team member shares some responsibility for the dysfunction.

Here's a scenario that commonly appears on exams: A Scrum Team asks the Product Owner to let the lead developer manage the Product Backlog ordering because the PO is extremely busy. Is this acceptable?

The correct framing isn't about whether the lead developer can do the work. It's that the Product Owner remains accountable for the value of the work. They can collaborate, consult, and even delegate specific tasks — but they cannot hand off the accountability. Exam answers that suggest the PO can "transfer" their accountability are always wrong.

The Practical Exam Mindset

When you see a question asking who is responsible for something, pause and ask yourself: is this question really asking about doing or owning? The correct Scrum Guide answer will almost always privilege accountability over responsibility. Look for the option that keeps ownership with the right person while allowing the team flexibility in execution.

---

The Scrum Master's Accountability: Fostering Team Effectiveness

The 2020 Scrum Guide defines the Scrum Master's accountability with clarity: they are accountable for the Scrum Team's effectiveness. Everything else flows from that central statement.

What does "team effectiveness" look like in practice? It means the team understands Scrum, practices it properly, continuously improves, and delivers value without unnecessary friction. A Scrum Master who is only scheduling meetings and sending calendar invites is failing this accountability. One who is actively coaching developers on self-management, helping the organization understand how to work with the Scrum Team, and removing impediments before they derail a Sprint — that's someone fulfilling the accountability.

A real-world example: imagine you're a Scrum Master and you notice your developers keep being pulled into ad hoc meetings by a stakeholder who bypasses the Product Owner entirely. Your accountability here isn't just to note the dysfunction — it's to address it. That might mean coaching the PO on how to assert their role, facilitating a conversation with the stakeholder, or escalating to leadership if the pattern persists. You don't fix it once and move on; you establish conditions that prevent it from recurring.

What the Scrum Master Is NOT Accountable For

This is equally important for the exam. The Scrum Master is not accountable for:

• The content of the Product Backlog (that's the PO)
• How the Developers build the product (that's the Developers)
• Delivery timelines or project deadlines in the traditional sense
• Assigning tasks to team members

A common trap question will suggest that the Scrum Master should step in and assign work during Sprint Planning or manage who does what during a Sprint. The correct answer will always reject this — that's the Developers' domain, not the Scrum Master's.

---

The Product Owner's Accountability: Maximizing Value

The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team's work. Again, this is an accountability — an outcome ownership — not merely a set of tasks.

The PO achieves this primarily through effective management of the Product Backlog. This means developing and explicitly communicating the Product Goal, creating and clearly expressing Product Backlog items, ordering those items to best achieve the goal, and ensuring the backlog is transparent and understood.

What's critical for the exam: the Product Owner is one person, not a committee. This is explicitly stated in the 2020 Scrum Guide. Organizations sometimes try to have a "proxy PO" or a panel of stakeholders who collectively make backlog decisions — Scrum pushes back hard on this. One person must be accountable for the Product Backlog. If that structure doesn't fit the organization, the organization needs to adapt to Scrum, not the other way around.

When the PO Delegates Work

Yes, the Product Owner can ask others to help refine backlog items, gather feedback, or update descriptions. What they cannot do is hand off the ordering authority or the accountability for value. An exam question might say: Stakeholders demand that the Product Owner include certain features immediately. What should the PO do? The answer should always reflect that the PO — not the stakeholders — decides the order of the Product Backlog. The PO listens to stakeholders, but they are not obligated to follow their demands.

---

The Developers' Accountability: Creating a Done Increment

The Developers — remember, that's everyone on the Scrum Team contributing to the Increment, excluding the Scrum Master and Product Owner unless they're also doing that work — are accountable for creating a usable Increment every Sprint.

Their specific accountabilities include:

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

That last point is often underemphasized. Scrum doesn't rely on the Scrum Master to enforce developer accountability. Developers are expected to be accountable to each other. If someone isn't meeting their commitments, it's the team's responsibility to address it — not to escalate to the Scrum Master as if they were a manager.

No Titles, No Sub-Teams

The 2020 Scrum Guide explicitly states there are no sub-teams or hierarchies within the Developers. There are no "senior developers" or "team leads" in the Scrum sense. If someone has a specialization — say, a UX designer or a database architect — they're still just a Developer when they're in the Scrum Team context. Exam questions that suggest a senior developer should oversee other developers' work, or that a technical lead should assign tasks, are almost certainly pointing toward incorrect answers.

---

Self-Managing vs. Self-Organizing: Why the Terminology Matters

The 2017 Scrum Guide used the term self-organizing. The 2020 guide replaced it with self-managing. This swap is frequently tested and often misunderstood.

Self-organizing implied that teams could decide how to do their work. That's still true — but it's a subset of the full picture.

Self-managing goes further. It means the Scrum Team decides who does what, when, and how. The team isn't just free to choose their methods; they have full ownership over their internal structure and processes. No external manager assigns tasks. No Scrum Master tells developers what to do. The team manages itself.

Here's a scenario: A manager tells the Scrum Master that they want to be involved in Sprint Planning to ensure the right developers are assigned to the right tasks. How should the Scrum Master respond?

The Scrum Master should coach the manager on how Scrum works — specifically, that the Developers self-manage their work, and external assignment of tasks undermines this principle. The Scrum Master should protect the team's self-management while finding appropriate ways to involve the manager (perhaps as a stakeholder in Sprint Review).

This scenario also illustrates servant leadership in action: protecting the team's ability to work within the Scrum framework is one of the most concrete things a Scrum Master does.

---

The Scrum Master as a True Leader Who Serves

The 2020 Scrum Guide introduced a phrase that deserves careful attention: the Scrum Master is described as a true leader who serves the Scrum Team and the larger organization. This replaced the earlier framing of "servant-leader," though the spirit is identical.

Servant leadership in Scrum means your primary job is to remove obstacles, enable others, and create conditions for success — not to direct, control, or manage. But don't mistake serving for being passive. A great Scrum Master is assertive when it counts.

They serve the Developers by coaching them on self-management, helping them create high-value Increments, removing impediments, and protecting them from distractions.

They serve the Product Owner by helping with effective Product Backlog management techniques, facilitating stakeholder collaboration, and helping establish empirical product planning.

They serve the organization by leading, training, and coaching Scrum adoption; helping employees and stakeholders understand and enact Scrum; and removing barriers between stakeholders and the Scrum Team.

A Scrum Master who only serves the team while ignoring the organizational context is missing half the job. This is a subtle point that differentiates intermediate understanding from genuine mastery — and it shows up in exam scenarios involving organizational change, cross-team coordination, and stakeholder management.

---

Common Exam Scenarios on Scrum Accountabilities

Understanding theory is one thing. Let's look at how these concepts appear in actual exam-style questions.

Scenario 1: The Product Owner is unavailable during Sprint Planning. The Scrum Master steps in to prioritize the Sprint Backlog. Is this correct?

No. The Product Owner is accountable for the Product Backlog and communicating the Sprint Goal. The Scrum Master should not substitute for the PO's accountabilities. The correct action is to reschedule Sprint Planning or bring in the available PO, not to absorb their accountability.

Scenario 2: Developers are debating who should lead the Daily Scrum. Can the Scrum Master facilitate it?

Yes, but with a caveat. The Scrum Master can facilitate the Daily Scrum if no one else is doing it, but the goal should be for the Developers to own this event themselves. The Scrum Master facilitating every Daily Scrum indefinitely suggests a self-management problem worth addressing.

Scenario 3: A stakeholder complains that a feature they requested last Sprint was never built. Who is accountable?

This is a nuanced one. The Product Owner is accountable for what was in the Sprint and in what order. The Developers are accountable for completing what was in the Sprint Backlog. If the feature was never put in the Sprint Backlog, that's a PO accountability issue. If it was in the Sprint Backlog and not completed, that's a Developers issue — and both cases suggest a Definition of Done or Sprint Planning quality problem worth examining.

---

Key Takeaways

• The 2020 Scrum Guide replaced roles with accountabilities — a shift from task ownership to outcome ownership.
• Accountability cannot be delegated the way responsibility can. The Product Owner remains accountable for value even if they delegate Backlog refinement tasks.
• The Scrum Master is accountable for Scrum Team effectiveness — not delivery timelines, not backlog content.
• Developers are accountable for creating a Done Increment every Sprint and hold each other accountable as professionals.
• Self-managing (2020) is broader than self-organizing (2017) — teams decide who does what, when, and how.
• The Scrum Master serves the team, the Product Owner, and the organization — all three, not just the immediate team.
• Exam questions are designed to test whether you understand accountability vs. responsibility at a nuanced level.

---

Conclusion

Mastering Scrum accountabilities is one of those areas where conceptual clarity pays dividends across dozens of exam questions. Once you can genuinely distinguish between who does the work and who owns the outcome, and once you internalize the shift from self-organizing to self-managing, many questions that seem tricky on the surface become straightforward.

The best way to lock in this understanding is to practice with scenario-based Scrum Master exam questions — the kind that present realistic organizational situations and ask you to identify the correct accountability-based response. Theoretical knowledge is the foundation, but applied practice is what builds the exam-day confidence you need to pass PSM I or CSM on your first attempt.

---

Frequently Asked Questions

Q: Can the Scrum Master also be the Product Owner?

A: The 2020 Scrum Guide explicitly states that the Scrum Master and Product Owner are separate accountabilities and should not be held by the same person. This isn't just a technicality — the Scrum Master is supposed to serve and coach the Product Owner, which creates an obvious conflict of interest if they're the same individual. Exam questions will always treat these as distinct accountabilities held by different people.

Q: Are Developers required to be software engineers?

A: No. In the 2020 Scrum Guide, "Developers" refers to anyone on the Scrum Team who works on creating the Increment — regardless of discipline. This includes testers, designers, business analysts, data engineers, and anyone else contributing to Done work. The term is deliberately broad. Some organizations even apply Scrum outside of software development entirely.

Q: What happens if the Scrum Master doesn't protect the team from external interference?

A: Failing to protect the team's ability to self-manage and focus on the Sprint Goal directly undermines the Scrum Master's core accountability: Scrum Team effectiveness. If a manager is constantly pulling developers into non-Sprint work, or stakeholders are making direct demands on the team that bypass the Product Owner, and the Scrum Master does nothing — they are failing in their accountability. The Scrum Master doesn't have authority to mandate organizational change, but they are expected to coach, advocate, and escalate until the issue is resolved.