What are the three accountabilities on a Scrum Team and what does each one own?

## One team, three accountabilities, and a closed list A Scrum Team is one small team — usually around ten people or fewer — that contains everything needed to turn an idea into a usable **Increment** each **Sprint**. Inside it the framework names exactly three accountabilities and then stops: **Product Owner**, **Scrum Master** and **Developers**. There is no project manager, no tester seat, no architect seat and no team lead in the framework's vocabulary. The word *accountability* is chosen over *role* on purpose. A role is something you are; an accountability is something you answer for. One person may hold two of them, and a company job title is untouched by any of this — Scrum describes what a team answers for, not how an organisation handles reporting lines, pay or hiring. ## Product Owner: one named person with ordering authority The Product Owner is accountable for the **value** the product delivers, and the visible instrument of that accountability is the order of the Product Backlog. They decide what the product needs next and what it does not need at all, they keep that ordering understandable to everyone, and they are answerable to stakeholders for the outcome. Two properties matter in an interview: - **It is one person, never a committee.** A group may advise; only one person decides, because ordering by consensus reintroduces exactly the delay the accountability exists to remove. - **The decision may not be quietly overridden.** The Product Owner can delegate the work — someone else may write the items, run the analysis, talk to customers — but the decision and the answerability stay put. Where the organisation routinely reverses that decision elsewhere, the accountability exists in name only. ## Scrum Master: effectiveness, not command The Scrum Master is accountable for the **team's effectiveness** and for the framework being understood and used as intended. Concretely: coaching the team in self-management and cross-functionality, helping the Product Owner with product planning and ordering technique, causing impediments to be removed — often by working on the organisation around the team rather than on the team itself — and helping stakeholders interact with the team the way the framework intends. What the accountability explicitly does not carry is authority: no assigning work to individuals, no setting the Product Backlog order, no appraisal, no status reporting on people. This is the most common misunderstanding of the three, which is why 'the Scrum Master is the team's manager' scores badly. ## Developers: collectively accountable for the Increment Developers are everyone on the team who does the work of building the Increment — including people whose job titles say tester, designer, writer, data engineer or operations. They create the plan for the Sprint, hold each other to the team's shared quality standard, adapt the plan daily toward the Sprint Goal, and are accountable **as a group** for a usable Increment. The collective part is not a politeness. It is what makes a team cross-functional instead of a chain of handoffs: when the Increment is unusable, the question is not which individual failed but what the team will change. ## The three at a glance | Accountability | Answers for | Decides | Does not decide | | --- | --- | --- | --- | | Product Owner | Value of the product | What is built next, and in what order | How work is built, or how much fits | | Scrum Master | Team effectiveness, correct use of the framework | Nothing about product content or task assignment | What is built, who does what, when it counts as finished | | Developers | A usable Increment each Sprint | How the work is done, how much is taken on | The product order, or whether the value was worth it | ## How this gets probed, and where teams go wrong Interviewers rarely stop at the three names. The follow-up is usually a boundary case: 1. **Who decides how much work enters a Sprint?** The Developers, because they do the work. A Product Owner who sets the amount has taken a decision that is not theirs. 2. **Who can tell a Developer what to work on today?** Nobody outside the Developers. Self-management is the mechanism, not a perk. 3. **Who judges that an item is worth having?** The Product Owner judges value; the Developers judge that the work meets the team's shared quality standard. Both have to be true. 4. **What if one person holds two accountabilities?** It is allowed and it is risky: a Product Owner who is also Scrum Master has nobody left to push back when they over-fill a Sprint. Failures worth naming out loud: treating Developers as only the programmers, which pushes everyone else into a downstream queue; a Scrum Master who runs the events and reports progress upward; and a Product Owner who is really a relay for somebody else's decisions.