Scrum Master Exam: The Developers Accountability (2026 Guide)

If there's one area where exam candidates consistently lose points, it's the Developers' accountability. Most people spend their prep time memorizing the Scrum Master's responsibilities or the Product Owner's backlog duties — and then get blindsided by a cluster of situational questions about what the Developers actually own, decide, and protect. Don't let that be you.

The 2020 Scrum Guide made a significant shift in language that many candidates overlook. The term "Development Team" was retired. In its place: simply Developers. This wasn't cosmetic housekeeping — it was a deliberate signal that the people doing the work aren't a sub-unit of the Scrum Team. They're a core accountability within it. Understanding why that distinction matters will change how you answer at least a dozen exam questions.

This guide is built for candidates preparing for the PSM I or CSM who want to go beyond surface-level definitions. We're going to cover everything — self-management, Sprint Backlog ownership, the Definition of Done, Daily Scrum mechanics, and the tricky boundary questions between Developers and the Scrum Master. By the time you finish, you'll be able to confidently handle situational questions that trip up even well-prepared candidates.

---

Who are the Developers in the Scrum Guide 2020?

The Scrum Guide 2020 defines Developers as "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint." That word any is doing real work in that sentence. It's explicitly rejecting the idea that Developers are only the software engineers. A tester, a UX designer, a database architect, a technical writer — anyone contributing to the actual work of creating an Increment is a Developer in Scrum's eyes.

This is a critical exam point. If a question describes a team member named Alex who writes acceptance tests, and asks whether Alex is a Developer, the answer is yes — even if Alex doesn't write a single line of application code. The role is defined by the type of contribution, not by a job title.

What's Different from the 2017 Guide?

The 2017 Scrum Guide used the term "Development Team" and described them as a distinct layer nested within the larger Scrum Team. That framing, despite Scrum's intentions, reinforced a perception that the Development Team was "the coders" and the Scrum Master and Product Owner were managers hovering above them. The 2020 revision collapsed that hierarchy entirely.

Now there's one Scrum Team with three accountabilities: the Product Owner, the Scrum Master, and the Developers. No sub-teams. No hierarchy between those three. This flat, collaborative structure is not just philosophical — the exam tests it directly through questions about who can instruct Developers on how to work (no one), who can add items to the Sprint Backlog mid-Sprint (only the Developers), and who owns the daily plan (also the Developers).

Typical Team Size and Composition

The Scrum Guide recommends that the Scrum Team, as a whole, be ten or fewer people. For the Developers specifically, there's no mandated minimum beyond the practical reality that you need enough people to create a meaningful Increment. In most real-world implementations, you'll see three to seven Developers. They're expected to be cross-functional — meaning the team collectively holds all the skills necessary to create value, without depending on anyone outside the team.

---

Key Accountabilities of Developers During the Sprint

The Scrum Guide assigns several explicit accountabilities to Developers. Knowing these cold will help you immediately eliminate wrong answers on the exam.

Developers are accountable for:

• Creating a plan for the Sprint — this is the Sprint Backlog, including the Sprint Goal and the plan for delivering the Increment
• Instilling quality by adhering to a Definition of Done
• Adapting their plan each day toward the Sprint Goal
• Holding each other accountable as professionals

That last point deserves emphasis. Scrum places professional accountability squarely on the Developers themselves. This isn't a team where the Scrum Master monitors individual performance or the Product Owner decides who does what. Developers self-manage, which means they're also responsible for calling each other out when quality slips or commitment wavers.

Sprint Planning: Where Accountability Begins

Sprint Planning is where Developer accountability becomes visible for the first time each Sprint. The Product Owner presents the most valuable items from the Product Backlog and explains why the Sprint matters. But here's where many candidates go wrong on the exam: the Developers decide how much work they can take on and how they will do it.

The Product Owner cannot assign story points, cannot dictate velocity, and cannot override the Developers' assessment of what's achievable. If a Product Owner says "I need all ten of these items delivered this Sprint," the Developers have both the authority and the accountability to push back and say, "We can realistically commit to six." That honest, professional response isn't resistance — it's exactly what Scrum expects.

---

The Developers' Role in the Daily Scrum

The Daily Scrum is a 15-minute event owned entirely by the Developers. Not the Scrum Master. Not the Product Owner. The Developers.

The Scrum Guide 2020 is explicit: the Daily Scrum is "for the Developers." Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The Developers choose their own structure for the meeting. They can use the classic three questions, they can do a walking board review, they can run it as a quick stand-up around a whiteboard — whatever helps them create a useful plan for the next 24 hours.

What About the Scrum Master?

Here's a classic exam trap. A question describes a scenario where the Scrum Master consistently runs the Daily Scrum, asks the three questions to each Developer, and facilitates the whole 15 minutes. Is this appropriate?

The answer is nuanced. The Scrum Master's role is to ensure the Daily Scrum happens and that Developers understand its purpose. If Developers are new to Scrum, the Scrum Master might initially model the format. But the long-term goal is for Developers to own this event themselves. A Scrum Master who permanently runs the Daily Scrum is, at best, a crutch — and at worst, actively undermining the self-management the Scrum Guide demands.

What About the Product Owner?

The Product Owner may attend the Daily Scrum, but only if the Developers invite them. They do not have an automatic right to participate, and they certainly don't direct the conversation. On the exam, if you see a scenario where the Product Owner regularly attends Daily Scrums and provides task assignments, that's a red flag for a Scrum anti-pattern.

---

Ownership and Management of the Sprint Backlog

The Sprint Backlog belongs to the Developers. Full stop. This is one of the most tested ownership boundaries on both the PSM I and CSM exams, and one of the most misunderstood in real-world practice.

The Sprint Backlog consists of three elements:

1. The Sprint Goal (the why)
2. The Product Backlog items selected for the Sprint (the what)
3. The actionable plan for delivering the Increment (the how)

Developers create and update the Sprint Backlog throughout the Sprint. When new work is discovered — maybe a technical dependency they didn't anticipate in Sprint Planning — they add it themselves. No approval needed from the Product Owner. No notification required for the Scrum Master. This is Developers managing their own work in real time.

Can Work Be Added to the Sprint Backlog Mid-Sprint?

Yes — but only by the Developers. This is a crucial distinction. If a stakeholder approaches the Product Owner during a Sprint and says, "Can we sneak this small feature in?", the Product Owner cannot simply inject it into the Sprint Backlog. They can negotiate with the Developers, they can remove something else to make space, or they can put it in the Product Backlog for the next Sprint. But the decision lives with the Developers.

Can Work Be Removed from the Sprint Backlog Mid-Sprint?

This is where the Sprint Goal becomes critical. Developers can adjust the scope of the Sprint Backlog as they learn more — but only in ways that don't jeopardize the Sprint Goal. If removing a specific Product Backlog item would make the Sprint Goal unachievable, that conversation needs to involve the Product Owner. Scope is flexible; the Sprint Goal is not casually discarded.

---

How Developers Uphold the Definition of Done (DoD)

The Definition of Done is one of the most important concepts in the entire Scrum Guide, and Developers are its primary guardians in day-to-day practice.

The DoD is a formal description of the state an Increment must be in to be considered complete. It creates transparency and shared understanding — without it, "done" becomes whatever is most convenient to claim at the Sprint Review. The Scrum Guide is clear: if an organization already has a DoD, Developers must follow it as a minimum standard. If not, the Developers create one themselves.

Why This Matters on the Exam

Exam questions about the DoD often test whether candidates understand who enforces it in practice. The Scrum Master champions it and coaches the team on its importance. The Product Owner accepts or rejects Increments based on it. But the Developers are the ones working against it every single day — checking each piece of work against the DoD before calling it done.

A common scenario question: "A Developer finishes a feature but skips the automated testing step because the Sprint is almost over. Is this acceptable?" The answer is no. Work that doesn't meet the DoD is not considered done. It cannot be included in the Increment. Period. The Developers' accountability for quality means that incomplete work must be returned to the Product Backlog, not presented as finished.

Raising the Bar on the DoD

Developers are also expected to improve the DoD over time. If the current DoD only requires unit testing, and the Developers know that integration testing would catch more defects, they should advocate for expanding it. Sprint Retrospectives are the natural venue for this conversation. This is part of what it means for Developers to be committed to quality — not just meeting the current bar, but continuously raising it.

---

Common Exam Questions: Developers vs. Scrum Master

The boundary between Developer and Scrum Master accountability generates more exam questions than almost any other topic. Here are the most common scenarios and how to think through them.

Scenario 1: The team is struggling to complete Sprint commitments. The Scrum Master starts assigning tasks to individual Developers based on their skills. Is this correct?

No. Task assignment is entirely within the Developers' domain. The Scrum Master's role is to coach, facilitate, and remove impediments — not to manage work allocation. A Scrum Master who assigns tasks is violating the self-management principle.

Scenario 2: A new Developer joins the team and asks the Scrum Master how to run the Daily Scrum. What should the Scrum Master do?

Coach the Developer on the purpose and options for structuring the Daily Scrum, then step back and let the team decide their own approach. The Scrum Master serves the team by building their capability, not by doing the event for them.

Scenario 3: A Developer disagrees with the Sprint Goal set during Sprint Planning. What should happen?

Sprint Planning is a collaborative event. If a Developer has concerns about the Sprint Goal, the right time to raise them is during Sprint Planning, before the Sprint begins. Once the Sprint starts, the team commits to pursuing the Sprint Goal together. The Scrum values of courage and openness apply here — Developers should speak up early, not stew silently.

---

Self-Management: How Developers Decide How to Work

Self-management is the beating heart of the Developers' accountability. The Scrum Guide states that Developers "are always accountable for... adapting their plan each day toward the Sprint Goal." No manager tells them how. No Scrum Master assigns tasks. No Product Owner prioritizes individual work items within the Sprint.

This means Developers decide:

• Who works on what
• In what order tasks are tackled
• What technical approaches to use
• How to respond when something unexpected comes up

Self-Management Isn't Chaos

A common misconception — both among exam candidates and real-world practitioners — is that self-management means "no coordination" or "everyone just does whatever they want." That's self-organization taken to a dysfunctional extreme. True self-management in Scrum means the team coordinates internally, makes decisions collaboratively, and holds each other accountable — without needing external direction.

In practice, this looks like Developers swarming on a blocked task rather than waiting for a manager to reassign it. It looks like a frontend Developer picking up a backend task during Sprint Planning because that's what the team needs to meet the Sprint Goal. It looks like the team collectively agreeing during a Daily Scrum to reprioritize their day based on new information.

The Scrum Values in Action

The five Scrum values — Commitment, Courage, Focus, Openness, and Respect — are most visibly expressed through how Developers work together. When a Developer commits to the Sprint Goal, that's not a passive acknowledgment. It's a professional promise. When they raise a concern about quality or timeline, that's courage. Self-management only works when these values are genuinely practiced, not just posted on a wall.

---

Key Takeaways

• Developers is the 2020 Scrum Guide term — not "Development Team." The change signals full accountability within a unified Scrum Team.
• Developers include anyone who creates any aspect of the Increment — regardless of job title.
• Developers own the Sprint Backlog and are the only people who can add or modify its contents.
• The Daily Scrum is for and by the Developers — the Scrum Master facilitates their understanding of it, but doesn't run it.
• Developers are the primary upholders of the Definition of Done in daily work.
• No one — not the Scrum Master, not the Product Owner — can tell Developers how to do their work. Self-management is non-negotiable.
• On exam questions, when in doubt about who decides how the work is done: it's the Developers.

---

Conclusion

Understanding the Developers' accountability at this level of depth puts you in the top tier of exam-ready candidates. Most people can recite that "Developers own the Sprint Backlog" — but fewer can confidently handle a scenario question where a well-meaning Scrum Master oversteps, or where a Product Owner tries to inject work mid-Sprint and the question asks what the team should do.

The real skill for the PSM I and CSM exams isn't memorization — it's applying these principles quickly under pressure, in scenarios that are deliberately designed to test the edges of your understanding. The best way to build that skill is through consistent practice with scenario-based questions that mirror the actual exam format. Work through as many situational examples as you can, pay attention to why each answer is correct, and trace every answer back to the Scrum Guide. That's the mindset that turns a prepared candidate into a certified one.

---

Frequently Asked Questions

Q: Can the Product Owner be a Developer on the same Scrum Team?

Technically, the Scrum Guide doesn't prohibit this, but it strongly discourages it. The Guide notes that while team members may have specialized skills and areas of focus, accountability must remain clear. In practice, combining the Product Owner and Developer roles in one person creates conflicts of interest — particularly around Sprint Backlog prioritization and Definition of Done enforcement. Most exam questions will treat these as distinct accountabilities held by different people.

Q: Who is responsible if the Increment doesn't meet the Definition of Done at the Sprint Review?

The Developers are accountable for the quality of the Increment and for adhering to the DoD. If work doesn't meet the DoD, it shouldn't have been presented at the Sprint Review in the first place — it should have been returned to the Product Backlog. The Scrum Master has a responsibility to coach the team on this, but the accountability for daily quality practice sits with the Developers.

Q: Can a Scrum Master also be a Developer?

Yes — the Scrum Guide explicitly allows this, noting it's often not optimal. In smaller organizations or early-stage teams, the same person sometimes holds both accountabilities. If this comes up on the exam, the key point is that the person must be clear about which accountability they're acting from at any given moment, and that the Scrum Master role must not compromise the Developers' self-management. This dual role works better in mature teams where Scrum practices are already well-established.