3.2 The Developers

Who Are the Developers?

The 2020 Scrum Guide defines Developers as the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. " The Guide is deliberate: the specific skills that Developers need are often broad and will vary with the domain of work. On a marketing product the Developers might be writers, designers, and analysts; on a hardware product they might be electrical and mechanical engineers; on a research product they might be scientists. What unites them is the single shared commitment — to produce a usable Increment every Sprint.

This term replaced the older "Development Team" in 2020 for a specific reason. The old wording implied a separate team-within-a-team, which encouraged exactly the hierarchy and hand-off thinking Scrum tries to eliminate. By naming the people (Developers) rather than a sub-team (Development Team), the 2020 Guide reinforces that there is one flat Scrum Team. The Developers are always part of that one team. They do not report to the Scrum Master or to the Product Owner, neither of whom has authority to assign them tasks.

This is one of the most heavily tested distinctions on PSM I, and trap answers frequently describe a Scrum Master or Product Owner "directing" or "assigning work to" the Developers.

The Four Developer Accountabilities

The 2020 Scrum Guide assigns the Developers exactly four accountabilities. Memorize them precisely, because PSM I frequently asks which item is — or is not — a Developer accountability, often mixing in Product Owner or Scrum Master responsibilities as distractors.

1. Creating a plan for the Sprint — the Sprint Backlog. The Developers, not the Product Owner and not the Scrum Master, build the plan for how selected Product Backlog items become a valuable Increment. They also forecast how much work to pull into the Sprint.
2. Instilling quality by adhering to a Definition of Done. Quality is built in, not inspected in afterward. The Developers hold their work to the Definition of Done for every Increment, and only work that meets the Definition of Done is part of an Increment.
3. Adapting their plan each day toward the Sprint Goal. Plans are not frozen when the Sprint starts. As the Developers learn more, they adjust the plan; the Daily Scrum is the event where this daily inspection-and-adaptation centers, but adaptation can happen any time new information arises.
4. Holding each other accountable as professionals. Accountability flows peer-to-peer within the Developers. It is not imposed downward by the Scrum Master, a manager, or the Product Owner.

How Developers Work Within the Team

Because the team is self-managing, the Developers decide how to turn Product Backlog items into Increments — no one outside the Scrum Team prescribes their technical approach. They select how much work to forecast into the Sprint during Sprint Planning, and as they learn more they may negotiate scope with the Product Owner without abandoning the Sprint Goal, which remains a fixed commitment for the Sprint. This balance — flexible on scope, firm on the Sprint Goal — is a favorite PSM I scenario.

A few precise distinctions worth holding:

• The Developers own the Sprint Backlog; the Product Owner owns the Product Backlog. The Sprint Backlog is by the Developers, for the Developers.
• The Developers are accountable for quality, expressed through the Definition of Done. If no organizational Definition of Done exists, the Developers must create one appropriate for the product.
• The Daily Scrum is for the Developers — it is their event to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The Scrum Master and Product Owner are not required to run it.

Worked scenario

Mid-Sprint, the Developers realize a chosen approach will not finish in time. Scrum-aligned behavior: they adapt the Sprint Backlog (their plan) and, if needed, talk with the Product Owner to renegotiate scope while protecting the Sprint Goal — they do not wait for the Scrum Master to reassign tasks, and they do not silently drop quality below the Definition of Done. That single scenario exercises three of the four Developer accountabilities at once.

Quality, the Definition of Done, and Daily Adaptation

The Developers' quality accountability deserves extra precision because PSM I tests it heavily. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. Several rules follow:

• Work that does not meet the Definition of Done cannot be released or even presented as Done at the Sprint Review — it returns to the Product Backlog for future consideration.
• If the Definition of Done is part of the organization's standards, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Developers of the Scrum Team must create one appropriate for the product.
• The Definition of Done creates transparency about the Increment; without it, no one can trust that "done" really means done. This is why quality is a Developer accountability rather than something inspected in later by a separate QA group.

Daily adaptation connects to the Daily Scrum, a 15-minute event for the Developers of the Scrum Team. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, producing an actionable plan for the next day of work. The Daily Scrum is owned by the Developers; the Scrum Master ensures it happens and stays within its time-box but does not run it, and if the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.

Trap distinctions to memorize