Understanding the three roles and their accountabilities.
The Scrum Team is a cohesive unit of professionals focused on one product.
There are no sub-teams or hierarchies—just three distinct accountabilities:
Note: The 2020 Scrum Guide uses "Developers" for everyone who creates the Increment, regardless of job title. Testers, designers, and others are all "Developers" in Scrum terms.
Team Size
Scrum Teams are typically 10 or fewer people. Smaller teams communicate better. If you need more people, consider multiple Scrum Teams.
The Product Owner is one person, not a committee. They are accountable for:
Developing and communicating the Product Goal The vision of where the product is heading. This guides all decisions.
Creating and ordering the Product Backlog Deciding what to build and in what sequence. This requires understanding value, risk, and dependencies.
Ensuring the backlog is transparent and understood The team should understand backlog items well enough to discuss them.
Key principle: The Product Owner may delegate these activities, but remains accountable for them. The organization must respect the PO's decisions—the backlog reflects their decisions, not a committee vote.
Sarah says 'no' to a stakeholder request that doesn't align with the Product Goal. She explains the trade-off and suggests an alternative for next quarter.
The 'Product Owner' is actually three people who vote on priorities. Decisions take days and nobody takes ownership of outcomes.
Developers are professionals who create any aspect of a usable Increment each Sprint. They are accountable for:
Creating a plan for the Sprint (Sprint Backlog) The Developers decide HOW to turn backlog items into an Increment.
Instilling quality by adhering to a Definition of Done Quality is non-negotiable. Done means done—not "done pending testing."
Adapting their plan each day toward the Sprint Goal The Sprint Backlog is a living plan, updated as the team learns.
Holding each other accountable as professionals Self-management means the team handles its own issues.
Key principle: No one tells Developers how to do their work. The Product Owner says WHAT to build; Developers decide HOW.
Common Misunderstanding
"Developers" doesn't mean "programmers only." QA engineers, UX designers, DBAs—anyone creating the Increment is a Developer in Scrum terms.
The Scrum Master is accountable for the Scrum Team's effectiveness. They serve the team and the organization by:
Helping the team improve its practices Coaching, facilitating, teaching. Not doing the work for them.
Removing impediments to the team's progress When something blocks the team that they can't resolve themselves, the Scrum Master helps remove it.
Ensuring Scrum events are productive and timeboxed Facilitation, not attendance-taking.
Helping the organization adopt Scrum Sometimes the biggest impediments are organizational. The Scrum Master addresses these too.
Key principle: The Scrum Master is a servant-leader—they lead by serving, not by commanding. They have no authority over the team except the authority of expertise and trust.
During retrospective, the SM notices a developer hesitating. They create space for that person to speak by asking a direct question, then protect them from interruption.
The 'Scrum Master' assigns tasks, reports status to management, and makes technical decisions for the team.
The three accountabilities create a balance of power:
Product Owner ↔ Developers PO decides WHAT and WHY. Developers decide HOW and commit to WHEN (based on their capacity, not external pressure).
Scrum Master ↔ Product Owner SM helps the PO with backlog management techniques and stakeholder communication. Coaches on effective product ownership.
Scrum Master ↔ Developers SM helps Developers self-organize, improve technical practices, and remove blockers. Never assigns work or micromanages.
The key tension: POs want more scope; Developers want sustainable pace; the SM ensures the process respects both.