The Scrum Guide is deliberate about the word "accountability." Not "role," not "responsibility," not "function." Accountability. The distinction carries weight: an accountability cannot be shared or delegated away. If you hold an accountability in Scrum, you own the outcome — whether or not you do all the work yourself.

The Scrum Master

The Scrum Master is accountable for the effectiveness of the Scrum Team. This covers two related areas: ensuring that Scrum is understood and enacted as defined, and enabling the team to continuously improve its practices and results.

What this looks like in practice is coaching rather than managing. The Scrum Master does not make product decisions — that belongs to the Product Owner. The Scrum Master does not make technical decisions — that belongs to the Developers. What the Scrum Master does is create the conditions for the team to make those decisions well: facilitating events productively, removing obstacles that are outside the team's control, and helping both the team and the wider organisation understand how Scrum is supposed to work and why.

The Scrum Master also serves the organisation — helping it understand what Scrum requires and working with stakeholders outside the team to remove structural impediments to the team's effectiveness. This outward-facing aspect of the role is often underemphasised. A Scrum Master who focuses exclusively on the team and ignores the organisational context is working with one hand behind their back.

The Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the team's work. This is a business accountability, not a technical one. The Product Owner owns the Product Backlog — its content, ordering, and communication — and is accountable for the decisions about what the team works on and in what sequence.

One person holds this accountability, but that person represents multiple stakeholders. The Product Owner bridges the relationship between the business and the development team. They translate strategic intent into ordered backlog items. They make trade-off decisions when capacity is limited. They participate in Sprint Reviews and ensure that what has been built actually reflects what was needed.

The effectiveness of a Product Owner depends on authority as much as skill. A Product Owner who cannot make real decisions about the backlog — because those decisions are made by a committee, a manager, or a steering group — cannot hold the accountability meaningfully. The organisation needs to invest genuinely in the Product Owner role for it to function as designed.

The Developers

The Developers are accountable for creating a usable Increment each Sprint — something that meets the Definition of Done and could, in principle, be released. "Developers" in Scrum does not mean exclusively software engineers: it refers to the people who do the work of turning backlog items into delivered value, whatever form that takes.

The Developers are self-managing within the Sprint. They decide how to do the work, not just what to do. This is a meaningful degree of autonomy that requires genuine trust from the Product Owner and the wider organisation. Teams that are told how to build things as well as what to build are not operating with the full Scrum accountability structure — they are operating as an implementation resource within a nominal Scrum process.

Why all three matter

Each accountability is in tension with the others by design. The Product Owner needs the Developers to commit to delivering value; the Developers need the Product Owner to commit to clear priorities and make real decisions; both need the Scrum Master to create the conditions for the relationship to be productive. None of the three accountabilities functions well in isolation.

Scrum teams rarely fail because of poor individual performance within these accountabilities. They more commonly fail because the accountability structure has been compromised: a Product Owner without authority, a Scrum Master without independence, or Developers without self-management. Getting the accountabilities right is not a process question. It is an organisational design question.