Scrum: accountabilities and commitments

Scrum is the most widely used agile framework, and the PMP exam assumes you know it well. The definitive description is the Scrum Guide, written by Ken Schwaber and Jeff Sutherland. Its current version dates from November 2020 and is deliberately short. In June 2025, Jeff Sutherland and co-authors published a Scrum Guide Expansion Pack with optional guidance on product strategy, outcomes and AI; it supplements the 2020 guide rather than replacing it. This lesson explains who is accountable for what in Scrum and the three commitments that keep the work focused. Lesson 4 covers the events and artifacts.

Scrum calls itself a lightweight framework, not a method. It defines a small number of roles, events, artifacts and rules, and leaves the rest (how to write requirements, which engineering practices to use, how to estimate) to the team. That is why you will see Scrum teams that look quite different from one another, and why exam answers that add heavy process to Scrum are usually wrong.

The Scrum Team

A Scrum Team is a small, cohesive unit with one product owner, one Scrum Master and the developers. The Scrum Guide describes it as typically ten people or fewer, because smaller teams communicate better and are more productive. There are no sub-teams and no hierarchy inside the team; everyone focuses on the same objective, the product goal. The team is cross-functional, meaning it has all the skills needed to create a valuable increment each sprint, and self-managing, meaning it decides internally who does what, when and how.

The Compass app Scrum Team has seven people. Amara Osei, the library's digital services manager, is the product owner. Jordan Reyes, an experienced agile lead from the library's IT department, is the Scrum Master. Five developers come from the development firm under contract: Sana and Luc build the app, Mei handles the connection to the library's catalogue system, Ravi focuses on testing and automation, and Tess on design and accessibility. Together they can take a story from idea to a tested, releasable feature without handing it to another group.

The product owner

The product owner is accountable for maximizing the value of the product resulting from the team's work. In practice that means developing and communicating the product goal, creating and clearly expressing product backlog items, ordering them, and making sure the backlog is transparent, visible and understood. The product owner may delegate some of this work, for example letting developers write stories, but remains accountable. The product owner is one person, not a committee, although that person represents the needs of many stakeholders.

For the product owner to succeed, the whole organization must respect their decisions. Those decisions show up in the content and order of the backlog and in the increment shown at the sprint review. If the branch manager wants a feature, she persuades Amara; she does not go directly to the developers. An exam scenario in which a senior stakeholder tells developers to drop their sprint work for an urgent request usually has the same answer: redirect the request to the product owner.

The Scrum Master

The Scrum Master is accountable for establishing Scrum as the Scrum Guide defines it, by helping everyone understand Scrum theory and practice, both within the team and in the organization, and for the team's effectiveness. The Scrum Guide describes Scrum Masters as true leaders who serve the team and the larger organization. Their work has three directions: serving the team (coaching self-management and cross-functionality, helping it focus on high-value increments, causing impediments to be removed, making sure events take place and are productive), serving the product owner (techniques for backlog management and product goal definition, facilitating stakeholder collaboration) and serving the organization (leading and coaching Scrum adoption, removing barriers between stakeholders and teams).

Note what the Scrum Master is not: a project manager who assigns work, a team lead who approves designs, or a secretary who runs meetings for others. Jordan does not tell Sana which story to pick up. When Mei is blocked because the library's catalogue vendor has not issued test credentials, Jordan does not write the code around it; he chases the vendor contact, escalates to the library's IT manager when needed and keeps the team informed. When the daily scrum drifts into a design debate, he helps the team notice and move the discussion to a smaller group afterwards.

The PMP exam often uses the generic term "agile lead" or "team facilitator" for this servant-leader role, and sometimes describes a project manager acting in it. The behaviours it rewards are the same: facilitate, coach, protect the team from disruption, remove impediments and let the team decide how to do its work.

The developers

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable increment each sprint. The word includes testers, designers, analysts and writers, not just programmers. Developers are accountable for 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. Scrum recognizes no titles among developers, regardless of the work each person does, which encourages people to help one another across specialties.

Cross-functional teams often grow "T-shaped" people: deep skill in one area and enough breadth to help in others. When Ravi's test automation backlog grows, Luc pairs with him for a day; when Tess is away, Sana can make small layout changes using the design system. That flexibility reduces the waiting that occurs when every task needs one specialist.

Scrum and the project manager

The Scrum Guide does not mention a project manager. That does not mean project managers disappear in organizations that use Scrum. In a hybrid project like Compass, the project manager integrates the app with the fit-out, technology and transition work, manages the contract with the development firm, reports to the board, manages project-level risks and helps the product owner with stakeholders. Inside the Scrum Team, they respect the team's self-management and the product owner's authority over the backlog.

In smaller organizations, one person may hold both the Scrum Master and project manager roles. That can work, but the combination carries a risk: the habits of a project manager who assigns tasks and tracks individuals can undermine self-management. If you are in that position, be explicit about which hat you are wearing, and lean toward facilitation inside the team.

The three commitments

Each Scrum artifact has a commitment that gives it focus and makes progress measurable. The product backlog commits to the product goal; the sprint backlog commits to the sprint goal; the increment commits to the definition of done.

The definition of done is shared by everyone who works on the product. If the organization has a standard for done, teams follow it at a minimum; if several teams work on one product, they share a definition of done. When a backlog item does not meet it, the item is not released or shown as complete at the sprint review; it goes back to the product backlog. Lesson 7 distinguishes the definition of done, which applies to all items, from acceptance criteria, which are specific to each item.

The Scrum values

Scrum's success depends on people living five values: commitment, focus, openness, respect and courage. Team members commit to achieving their goals and supporting one another; they focus on the sprint's work; they are open about the work and its challenges; they respect each other as capable, independent people; and they have the courage to do the right thing and work on tough problems. The values are not decorative. A team that hides problems (no openness) or never questions the product owner's priorities (no courage) loses the transparency that empiricism needs.

Common Scrum anti-patterns

Exam scenarios often describe a team that uses Scrum's vocabulary while breaking its intent. Recognizing the pattern points to the answer. A proxy product owner who must check every decision with someone else slows the team and blurs accountability; the fix is to give the real decision maker the role or delegate genuine authority. A Scrum Master who acts as a task manager undermines self-management; the fix is coaching and stepping back. A "hardening sprint" at the end of every release, used to do the testing the team skipped, signals a weak definition of done; the fix is to build that work into every sprint. And a team that changes its members every few sprints loses the stability that makes forecasting and trust possible.