PSM I Scrum Team: Developers, Product Owner and Scrum Master Accountabilities

A Scrum Team is the fundamental unit of Scrum: a small team made up of one Scrum Master, one Product Owner and Developers. All three accountabilities sit inside the team. The Product Owner is a member of the Scrum Team, not its customer or an outside stakeholder, and the Scrum Master is a member too, not a manager placed above it.

The Scrum Guide describes the team as a cohesive unit of professionals focused on one objective at a time, the Product Goal. Two consequences follow:

• No sub-teams. A testing group, a design group or a database group inside the Scrum Team breaks the single team. Specialists stay specialists, but they work as members of one team.
• No hierarchies. Nobody inside the team is the boss of the others: no lead tester who signs off colleagues' work, no lead developer who assigns tasks, and no Scrum Master who directs the Developers day to day.

Scrum calls these three "accountabilities", not job titles or roles. A person is accountable for something; the Guide says nothing about job titles, line management, appraisals or reporting lines, so the absence of a rule there is not a rule either way.

A Scrum Team is typically 10 or fewer people, counting everyone: Developers, the Product Owner and the Scrum Master. It should be small enough to remain nimble and large enough to complete significant work within a Sprint. The Guide's reason for keeping it small is that, in general, smaller teams communicate better and are more productive.

"Typically" is guidance, not a hard cap. If a team becomes too large, the Guide says it should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Because they build one product, those teams share:

• one Product Goal,
• one Product Backlog, and
• one Product Owner.

The rule is one product, one goal, one backlog, one owner, however many teams work on it. Size and skills interact: the size guidance never justifies leaving the team without a skill it needs. Bring the skill into the team, and if that makes the team too large, reorganize into several cohesive teams on the same product.

Cross-functional means the team's members together have all the skills necessary to create value each Sprint. It does not mean every person can do every task, nor that the team holds one representative from each company department, nor that people rotate accountabilities.

The practical test is dependency. If a Done, usable Increment has to wait for a group outside the team (for example, a separate localization group that must translate every screen before release), the team is not fully cross-functional. The fix removes the dependency rather than managing it: the skill ends up inside the team, held by its Developers, whether a person who has it joins or existing members learn it. Coordinating better with the outside group, or reorganizing the skill into a sub-team, leaves the hand-off in place.

Scrum Teams are also self-managing: they decide internally who does what, when and how. Self-management is covered in its own lesson; here, the point is that it rules out anyone, including the Scrum Master or a line manager, assigning work to Developers.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Developers build it, but value and usefulness are not "the Developers' problem" or "the Product Owner's problem" alone; the team owns the result.

The Scrum Team is also responsible for all product-related activities. The Guide lists them as:

• stakeholder collaboration,
• verification,
• maintenance,
• operation,
• experimentation,
• research and development,
• and anything else that might be required.

So there is no hand-off of operations to a separate support team, no research phase done by someone else before the first Sprint, and no outside test group. The organization structures and empowers the team to manage its own work, and working in Sprints at a sustainable pace improves focus and consistency.

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The word describes an accountability, not a programming job. Testers, UX designers, analysts, technical writers and database specialists in the team are all Developers. The skills Developers need are often broad and vary with the domain of work, so a team producing an online training course might have instructional designers, video editors and subject-matter experts as its Developers.

The Developers are always accountable for four things:

1. Creating a plan for the Sprint, the Sprint Backlog. All Developers take part, not just the ones who write code. Nobody outside the Developers adds tasks to that plan or assigns its items.
2. Instilling quality by adhering to a Definition of Done. Quality is built in by the Developers themselves; it is not inspected in later by the Scrum Master or the Product Owner.
3. Adapting their plan each day toward the Sprint Goal. If they find a better approach mid-Sprint and the Sprint Goal is unchanged, they change their tasks themselves; no approval is needed.
4. Holding each other accountable as professionals. When a teammate marks work finished without meeting the Definition of Done, the Developers deal with it first, among themselves.

The Product Owner may discuss and negotiate scope with the Developers, but the plan for how the work gets done belongs to the Developers. The Sprint Backlog itself, the Sprint Goal and the Definition of Done are covered in the events and artifacts lessons.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Value is an outcome, not output: more features shipped, higher velocity or delivering a fixed scope on a fixed date are not the same thing as value. The Guide deliberately does not prescribe a method; how value is maximized may vary widely across organizations, Scrum Teams and individuals.

The Product Owner is also accountable for effective Product Backlog management, which the Guide breaks into four parts:

• developing and explicitly communicating the Product Goal;
• creating and clearly communicating Product Backlog items;
• ordering Product Backlog items;
• ensuring the Product Backlog is transparent, visible and understood.

Note what is not there: the Product Owner does not create the Sprint plan, does not decide how many items the Developers select for a Sprint, and is not required to run any particular meeting.

Delegation keeps accountability

The Product Owner may do this work personally or delegate the responsibility to others, for example asking Developers to write and refine items. Either way, the Product Owner remains accountable. Delegation needs nobody's approval, and it does not move accountability to the people doing the work.

The Product Owner is one person, not a committee. No group, however senior, can act as the Product Owner. The Product Owner may represent the needs of many stakeholders in the Product Backlog, but one person decides.

Anyone who wants to change the Product Backlog does so by trying to convince the Product Owner. That means:

• a customer-support lead who wants a fix prioritized takes it to the Product Owner, not straight to the Developers;
• a stakeholder who disagrees with the order makes the case to the Product Owner; the Scrum Master can help them do so, but does not reorder the backlog;
• a busy Product Owner gets help (delegation, coaching on techniques), not a second Product Owner, and stakeholders do not rank their own requests directly.

For Product Owners to succeed, the entire organization must respect their decisions. Those decisions are visible in the content and ordering of the Product Backlog and through the inspectable Increment at the Sprint Review. Those two places, not any separate approval record, are where the organization sees what the Product Owner decided.

The Scrum Master is accountable for two things:

• Establishing Scrum as defined in the Scrum Guide, by helping everyone understand Scrum theory and practice, both within the Scrum Team and across the organization.
• The Scrum Team's effectiveness, by enabling the team to improve its practices within the Scrum framework. Improving inside the framework rules out "improvements" that remove or replace parts of Scrum, such as swapping the Sprint Retrospective for something else.

The Guide calls Scrum Masters true leaders who serve the Scrum Team and the larger organization. They are not project managers coordinating delivery plans, team leads directing daily work, or process owners who approve how the team works. They are not accountable for product value (that is the Product Owner) or for the Sprint plan (that is the Developers), and they do not manage dates, scope and budget.

The Scrum Master's accountability is effectiveness, not quality control. Helping the team focus on Increments that meet the Definition of Done is a service; checking every item against the Definition of Done is not, because the Developers instil quality themselves.

The Guide lists the Scrum Master's services in three groups. Each one helps or enables; none of them takes a decision away from the accountability that owns it. For example, helping the Product Owner with backlog techniques never becomes ordering the backlog, and coaching the organization never becomes making its management decisions.

"Causing the removal" of impediments

The wording matters. When an impediment is outside the team's control, such as a software licence held up in another department's purchasing process, the Scrum Master works with whoever can remove it. When the impediment is within the Developers' own control and skills, such as a set of unreliable automated tests they wrote, the Scrum Master coaches them to resolve it rather than fixing it personally; that builds self-management.

Empiricism toward the Product Owner and the organization

When a Product Owner wants to lock a year of features to calendar dates, or executives expect a guaranteed completion date for work nobody has done before, the Scrum Master helps them adopt empirical planning that adapts as the team learns. It is the same service in two directions: product planning for the Product Owner, an empirical approach for the organization.

Each decision or outcome in Scrum has one owner: value and the Product Backlog belong to the Product Owner, the Sprint plan and quality to the Developers, Scrum's adoption and the team's effectiveness to the Scrum Master, and the Increment to the whole Scrum Team.

Older-Guide and folk-Scrum terms

The 2020 Scrum Guide replaced several terms that still circulate in courses and forums. PSM I uses the 2020 Guide.