3.3 Developers Accountability

3.3 Developers Accountability

Scrum Guide 2020: Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

On PSPO I, “Developers” is frequently misunderstood. It is not a synonym for programmers only. Anyone on the Scrum Team committed to creating the Increment—testers, designers, analysts, operations specialists, writers, scientists, or engineers—acts under the Developers accountability for that product domain.

Product Owners who treat Developers as an order-taking factory will miss questions about self-management, Sprint Backlog ownership, estimation, and quality.

---

The Four Developer Accountabilities

The Guide lists four accountabilities for Developers:

Creating a usable Increment

Every Sprint, Developers aim to produce a usable Increment—a concrete stepping stone toward the Product Goal that meets the Definition of Done. “Usable” means it could provide value; whether it is released is a Product Owner decision. Multiple Increments may be created within a Sprint; the sum of Done work is inspected, especially at the Sprint Review.

If the team consistently fails to produce a Done Increment, the problem may be over-selection of work, unclear PBIs, skills gaps, DoD that is ignored, or organizational impediments—not merely “Developers working harder.”

---

Sprint Backlog Ownership

The Sprint Backlog is composed of:

1. The Sprint Goal (why the Sprint matters)
2. The Product Backlog items selected for the Sprint (what will likely be done)
3. An actionable plan for delivering the Increment (how the team will work)

Developers are accountable for the Sprint plan. During the Sprint, they may renegotiate scope with the Product Owner if new information emerges, but they do so while protecting the Sprint Goal when possible. The Product Owner does not rewrite the Sprint Backlog unilaterally mid-Sprint as a personal task board.

Exam trap: A stakeholder tells the Product Owner to add three new items mid-Sprint and the PO inserts them into the Sprint Backlog without Developer agreement. That undermines self-management and Sprint Goal focus. Correct pattern: inspect impact with Developers; renegotiate if needed; or place items on the Product Backlog for future Sprints; cancel only if the Sprint Goal is obsolete (PO authority).

---

Definition of Done Quality

Developers instill quality by adhering to the Definition of Done. Done is not optional documentation; it is the quality bar that makes Increments transparent and potentially releasable.

Product Owner implications:

• Do not redefine Done downward under deadline pressure. Undone work is not part of the Increment.
• Acceptance of business intent is not a substitute for DoD. A feature can match the user’s story and still fail automated tests, security checks, or integration criteria in the DoD.
• When multiple teams share a product, they share a minimum DoD; individual teams may adopt a stricter DoD but not a weaker one that breaks integration transparency.

---

Daily Adaptation Toward the Sprint Goal

Developers adapt their plan each day toward the Sprint Goal. The Daily Scrum is a 15-minute event for the Developers to inspect progress and update the Sprint Backlog plan. The Product Owner may attend if the team finds it useful, but it is not a status report to the PO or to management.

Healthy PO behavior during the Sprint:

• Be reachable for clarification of Product Backlog items and acceptance intent
• Watch for Sprint Goal risk and engage early if value assumptions change
• Avoid converting Daily Scrum into a personal briefing
• Bring new opportunities to the Product Backlog (and Sprint Review / Planning), not as silent mid-Sprint scope dumps

---

Holding Each Other Accountable

Developers hold each other accountable as professionals. This is peer accountability—not hierarchical management by a tech lead titled “Developer Manager,” and not accountability enforced by the Product Owner through individual task assignment.

Inside the Developers group there are no sub-teams or special titles that create hierarchy for Scrum purposes. Skills differ; accountability for the Increment is collective.

---

Who Sizes Work? Who Selects How Much for a Sprint?

This is a high-frequency PSPO topic.

Developers size the work

Effort, complexity, and risk associated with turning Product Backlog items into Done Increments are best understood by the people doing the work. Developers size / estimate Product Backlog items (using whatever technique the team finds useful—the Guide does not mandate story points). The Product Owner may provide value context and split large items, but the PO does not unilaterally declare “this is a 2; finish five of them.”

Selecting how much work for the Sprint

During Sprint Planning, the Scrum Team collaborates. In practice:

The Product Owner brings an ordered Product Backlog and clarifies items. Developers forecast what they can deliver. Negotiation is normal: the PO may trade scope for value density; Developers may ask to refine unclear items before selection. What is not normal is the PO forcing a forecast the Developers do not believe, then blaming the team for “missing commitment.”

Forecast vs. fixed scope promise: Scrum uses empirical forecasts. A Sprint Goal focuses value; the exact set of PBIs can adapt if the Goal remains achievable. Treating the Sprint as a fixed iron triangle of scope set by the PO alone is a classic anti-pattern.

---

WHAT vs HOW: The Product Owner Boundary

If a Product Owner dictates implementation details and individual assignments, they have crossed from value ownership into work management—undermining self-management and usually reducing quality and speed of learning.

---

Common Anti-Patterns Involving Developers (PO View)

1. PO assigns daily tasks — breaks self-management.
2. PO estimates for Developers — breaks ownership of sizing and creates false forecasts.
3. PO softens DoD to hit a demo date — destroys transparency of the Increment.
4. Developers change Product Backlog order without PO — breaks PO accountability for value.
5. Separate “Dev” and “QA” Scrum Teams hand off work — creates sub-team hierarchies and delays a usable Increment.
6. Only specialists may touch their component; no shared Increment ownership — weakens collective accountability.

---

PSPO Collaboration Checklist with Developers

Use this as a mental model during exam scenarios:

• Are top Product Backlog items clear enough that Developers can create a Sprint plan?
• Did Developers size the work and choose a realistic forecast?
• Is there a shared Sprint Goal, not only a shopping list?
• Is the Definition of Done protected?
• Is the PO available for clarification without micromanaging tasks?
• Are mid-Sprint changes negotiated against the Sprint Goal rather than forced?

If those answers are yes, you are operating in line with Developer accountability as the Scrum Guide defines it—and as PSPO I expects you to protect.