The Scrum Team and Its Accountabilities: Product Owner, Scrum Master and Developers
In the Scrum Guide 2020 there is a single Scrum Team with three accountabilities: a one-person Product Owner who maximizes value, a Scrum Master accountable for the team's effectiveness, and Developers, testers, DevOps and designers included, who create the Increment. The post covers the shift from roles to accountabilities and from Development Team to Developers, and the traps of a Product Owner committee, proxies, separate QA teams and secretary Scrum Masters, using the Bookstore team.
Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. Comparisons with earlier versions rely on the revision history on scrumguides.org.
Guess First
It is the second week of Bookstore's move to Scrum. Management comes with four proposals: the Product Owner of the returns project should be a board of three, made up of the sales, accounting and customer service managers; Scrum Master Kerem should take meeting notes and update the tickets in Jira; testing should stay in a separate QA (Quality Assurance) team, with Deniz giving "support" from there; and Zeynep, the Angular developer, should spend two days a week on another project.
How many of these four proposals directly contradict the Scrum Guide 2020? Which one does not contradict it but still slows the team down? You will find the answer in the table in the middle of the post.
One Scrum Team, Three Accountabilities
According to the Guide, the fundamental unit of Scrum is a small team: one Scrum Master, one Product Owner and Developers. There are no sub-teams or hierarchies inside; it is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The team is cross-functional, meaning all the skills needed to create value each Sprint are inside it. The team is self-managing, meaning it decides internally who does what, when and how.
Two changes in the 2020 version look small here and have big consequences. The first is the removal of "Development Team". Up to 2017, a separate Development Team was defined inside the Scrum Team; the revision notes say this "team within a team" led to "us and them" behavior and proxies between the Product Owner and the developers. Now there is a single Scrum Team with three different accountabilities: Product Owner, Scrum Master and Developers.
The second is "self-managing" instead of "self-organizing". In the old Guide, the developers chose who did the work and how; in 2020 the whole Scrum Team is defined as a unit that manages its own work and also decides what to work on. This does not remove the Product Owner's authority to order the backlog; it says the "what" is not dictated from outside the team.
For team size, the 2017 Guide gave a range of 3 to 9 Developers. The 2020 version softened the number: the Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, "typically 10 or fewer people". Bookstore's seven-person team sits right in the middle of that definition.
Accountability, Not Role
The 2020 Guide does not use the word "role"; it says there are "three specific accountabilities" in the team. The difference: a role reads like a title or a position, while an accountability means being answerable for an outcome. The Product Owner is accountable for maximizing value, the Scrum Master for the team's effectiveness, and the Developers for creating a usable Increment. On top of that, the entire Scrum Team is jointly accountable for creating a valuable, useful Increment every Sprint.
The practical meaning of accountability shows up in delegation. The Guide states plainly that the Product Owner may delegate Product Backlog work to others and still remains accountable. Selin can have Ayşe write the description of an item; Selin still answers for why that item sits where it does. Where titles and accountabilities get mixed up, the opposite happens: someone with the title "Product Owner" who cannot make a single ordering decision, or someone hired as "Scrum Master" who never deals with the team's effectiveness.
Developers: Testers, Designers and DevOps Included
The Guide defines Developers as the people committed to creating any aspect of a usable Increment. Titles do not matter here. At Bookstore, Can's title is "DevOps Engineer" and Deniz's is "Test Automation Engineer"; both are Developers in Scrum. If a UX (User Experience) designer produces part of the Increment, they are a Developer too. The Guide explicitly notes that it uses the word to simplify, not to exclude.
The skills Developers need vary with the domain, but the Guide says they are always accountable for four things: creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to the Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals. The fourth is the least discussed: a missing test waved through in code review with "we'll look at it later" means the team is not enforcing its own standard, and fixing that is the Developers' job, not the Scrum Master's.
The "how" decision in Sprint Planning belongs entirely to the Developers as well. The Guide says no one else tells them how to turn Product Backlog items into Increments. At Bookstore, the Developers make the architecture decisions; a Software Architect's opinion can be valuable input, but cannot dictate to the team how to build.
Product Owner: One Person, Not a Committee
The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team's work. How this is done varies across organizations; the Guide only lists the four parts of Product Backlog management: developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering the items, and ensuring the Product Backlog is transparent, visible and understood.
The sharpest sentence in this section of the Guide is this: the Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog; anyone who wants to change the Product Backlog does so by convincing the Product Owner. Bookstore's board-of-three-managers proposal contradicts exactly this. If three people order the backlog at the same time, there is no order; in every Sprint Planning the team tries to guess whose priority wins.
The Guide's second condition for the Product Owner concerns the organization: for the Product Owner to succeed, the entire organization must respect their decisions. Those decisions are visible in the content and order of the Product Backlog and in the inspectable Increment at the Sprint Review. If a director breaks the backlog Selin ordered by saying "squeeze this in" in a corridor, Selin may have the title, but the accountability lives elsewhere. The difference between a Product Owner and a Product Manager, and the work of product discovery, are covered in the Introduction to Product Management series post "What Is Product Management? Product Manager vs Product Owner vs Project Manager".
Scrum Master: A True Leader Who Serves
The Scrum Master is accountable for two things: establishing Scrum as defined in the Guide, and the Scrum Team's effectiveness. The 2017 phrase "servant-leader" became "true leaders who serve the Scrum Team and the larger organization" in 2020. The shift in emphasis is deliberate: the Scrum Master is not a passive facilitator but someone who enables the team to improve its practices.
The Guide lists the Scrum Master's service to three parties. To the team: coaching in self-management and cross-functionality, helping focus on valuable Increments that meet the Definition of Done, causing the removal of impediments, and ensuring events take place and are positive, productive and within the timebox. To the Product Owner: finding techniques for Product Goal definition and Product Backlog management, helping the team understand the need for clear and concise items, establishing empirical product planning for a complex environment, and facilitating stakeholder collaboration. To the organization: leading, training and coaching Scrum adoption, planning Scrum implementations, helping employees and stakeholders understand an empirical approach, and removing barriers between stakeholders and teams.
Notice that the list does not contain "taking meeting notes", "updating Jira tickets" or "preparing status reports". The impediment wording is "causing the removal of impediments" as well: Kerem does not have to fix the constantly failing staging environment himself; he has to start the conversation that gets Can and the infrastructure team to solve it.
Grading Bookstore's Proposals
Let us evaluate the four proposals against the Guide:
| Proposal | Relation to the Guide | A better option |
|---|---|---|
| A Product Owner board of three managers | Direct contradiction: the Product Owner is one person, not a committee | Selin is the Product Owner; the managers attend the Review as stakeholders and convince Selin |
| The Scrum Master takes notes and updates tickets | Not forbidden, but the accountability is left empty; nobody works on the team's effectiveness | The Developers update the board; Kerem looks at why the team is slowing down |
| Testing in a separate QA team | Contradiction: the team must be cross-functional with no sub-teams; the Increment must be verified within the Sprint | Deniz is a Developer on the Scrum Team; testing is part of the Definition of Done |
| Zeynep on another project two days a week | The Guide does not forbid it, but it weakens focus and the team's capacity forecast | If sharing is unavoidable, capacity is discussed openly in Sprint Planning |
Two proposals directly contradict the Guide; two do not, but slow the team down. The distinction matters: being consistent with the Guide does not make every decision good, but contradicting the Guide always has a cost.
In Production: What to Watch
There are simple ways to measure whether accountabilities live only on paper. For the Product Owner: how many hours does it take to answer a question the Developers ask about an item during the Sprint? At Bookstore, when Selin's response time went past two days, the team started writing code on assumptions and two items came back at the Review. For the Scrum Master: how many teams do they serve, and how many actions from the last three Retrospectives were applied? For the Developers: how many items completed in the Sprint waited for someone outside the team (a separate test team, a separate deployment team)?
On scale, the Guide's advice is clear: if the team grows too large, it should consider reorganizing into multiple cohesive Scrum Teams focused on the same product, and those teams should share the same Product Goal, Product Backlog and Product Owner. Assigning a separate "Product Owner" to each team after a split is doing the exact opposite of the Guide.
Common Pitfalls
The Scrum Master turning into a meeting secretary. Someone who arranges the event calendar, updates Jira and hands out turns in the Daily Scrum is not accountable for the team's effectiveness; they only carry administrative load. The team then stops proposing improvements in the Retrospective too, because nobody will follow up on them.
The Product Owner proxy. The real decision maker (usually a director) never talks to the team; an analyst with the title "Product Owner" carries their wishes and forwards every question upward with "let me check". This is exactly the "us and them" behavior the 2020 revision notes set out to remove.
The part-time Developer. A developer split across three teams cannot own any team's Sprint Goal; they attend every team's Daily Scrum and really work in none. The Guide does not forbid this, but it directly weakens the value of focus.
Separate structures such as a "QA team" or a "deployment team". If the Increment must be verified and usable before the Sprint ends, the people doing the verification must be inside the team. Otherwise each Sprint's work waits in another team's queue in the next Sprint and a mini-waterfall begins; the tenth post of the series covers this anti-pattern in detail.
A Small Experiment
★☆☆ Write down the name of everyone on your team and add their accountability in the Guide. Mark the people whose title differs from their accountability (for example someone whose title is "Tech Lead" but who is a Developer in Scrum).
★★☆ Recall three ordering decisions from the last Sprint attributed to the Product Owner. Who actually made each decision? If it was not the Product Owner, where does the Guide's sentence "the entire organization must respect their decisions" break in your setting?
★★★ Make a three-column list of the Scrum Master's services to the team, the Product Owner and the organization, and write the concrete work done in each column over the last month. If the organization column is empty, that gap may explain why the team's impediments keep coming back.
The team is settled. In the next post we move to Selin's main tool: why the Product Backlog is an "ordered" rather than a "prioritized" list, what the Product Goal added in 2020 is for, and when a Definition of Ready, which is not in the Guide, helps and when it turns into a gatekeeper.