Scrum Explained in Plain English

Scrum is one of the most widely used ways of organizing agile teams, and also one of the most misunderstood. Many people learn it secondhand, through a company's adapted version, and end up thinking Scrum requires things it never mentions, such as story points, three standard questions at the daily meeting or a project manager assigning tasks.

The definitive description of Scrum is the Scrum Guide, written by Ken Schwaber and Jeff Sutherland and published free at scrumguides.org. As of this writing, the current edition is the November 2020 version. It is short, under 13 pages according to the site's own revision notes, and worth reading in full.

This guide explains what the 2020 Scrum Guide actually says, in plain English: the theory behind Scrum, who does what, the events, the artifacts and the commitment attached to each artifact.

What Scrum Is, and What It Is Not

The Scrum Guide defines Scrum as "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." The key word is framework. Scrum sets out a small number of roles, events and artifacts, and deliberately leaves the details of how to build things to the team.

Scrum rests on empiricism, the idea that knowledge comes from experience and decisions should be based on what is observed, and on lean thinking, which reduces waste and focuses on essentials. The Guide names three pillars that make empiricism work: transparency (the work is visible), inspection (it is checked frequently) and adaptation (things are adjusted as soon as a problem is found).

It also names five values: commitment, focus, openness, respect and courage. These are not decoration. Without openness, for example, transparency breaks down, and inspection is based on a misleading picture.

What Scrum does not include is just as important. The Guide does not mention story points, velocity targets, specific board layouts or user story templates. Teams can use those practices within Scrum, but they are add-ons, not requirements.

The Scrum Team and Its Three Accountabilities

A Scrum Team consists of one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies. The Guide says the team is typically 10 or fewer people. It is cross-functional, meaning the members together have all the skills needed to create value each Sprint, and self-managing, meaning they decide internally who does what, when and how.

The 2020 edition describes three accountabilities rather than job titles:

• Developers are the people committed to creating a usable Increment each Sprint. They are accountable for creating 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 word covers anyone doing the work, not only programmers.
• The Product Owner is accountable for maximizing the value of the product and for managing the Product Backlog, including the Product Goal and the ordering of items. The Product Owner is one person, not a committee, and others who want to change the backlog do so by convincing that person.
• The Scrum Master is accountable for establishing Scrum as defined in the Guide and for the team's effectiveness. The Scrum Master serves the team (for example, by coaching self-management and causing the removal of impediments), the Product Owner (for example, with backlog techniques) and the wider organization as it adopts Scrum.

The Five Events

Scrum uses timeboxes, which are maximum durations, to keep events focused. The Sprint contains the other four events. The timeboxes below are the maxima for a one-month Sprint; for shorter Sprints, the Guide says the events are usually shorter.

• The Sprint is a fixed-length event of one month or less. A new Sprint starts immediately after the previous one ends. Only the Product Owner can cancel a Sprint, and only if the Sprint Goal becomes obsolete.
• Sprint Planning (up to eight hours) answers three questions: why this Sprint is valuable, what can be done, and how the chosen work will get done. The whole Scrum Team collaborates on a Sprint Goal.
• The Daily Scrum (15 minutes) is for the Developers to inspect progress toward the Sprint Goal and adjust their plan. The 2020 edition removed the three standard questions, so teams can use whatever structure helps.
• The Sprint Review (up to four hours) is a working session in which the team and key stakeholders look at what was accomplished and decide what to do next. The Guide says it should not be limited to a presentation.
• The Sprint Retrospective (up to three hours) is where the team plans ways to increase quality and effectiveness. It concludes the Sprint.

Product Backlog refinement, the ongoing work of breaking down and clarifying backlog items, is described in the Guide as an activity, not an event. Teams do it as needed rather than in a prescribed meeting.

The Three Artifacts and Their Commitments

Scrum has three artifacts, and the 2020 edition gives each one a commitment that provides focus and a way to measure progress:

• The Product Backlog is an emergent, ordered list of what is needed to improve the product. Its commitment is the Product Goal, a future state of the product that the team plans against.
• The Sprint Backlog contains the Sprint Goal (why), the selected backlog items (what) and an actionable plan for delivering them (how). It belongs to the Developers and is updated throughout the Sprint. Its commitment is the Sprint Goal, the single objective for the Sprint.
• The Increment is a concrete stepping stone toward the Product Goal. It must be usable, and multiple Increments can be created within a Sprint. Its commitment is the Definition of Done, a formal description of the quality the Increment must meet.

The Definition of Done deserves special attention. If a backlog item does not meet it, the item cannot be released or even presented at the Sprint Review. That rule keeps "almost done" work from being counted as progress.

Scrum in Practice: A Hypothetical Sprint

Imagine a team of seven building a mobile app for booking fitness classes, working in two-week Sprints. In Sprint Planning, the Product Owner explains that users are abandoning bookings at the payment step. The team agrees on a Sprint Goal: make it possible to complete a booking with a saved card. The Developers select the backlog items that support that goal and break them into tasks.

Each morning, the Developers spend no more than 15 minutes checking progress toward the goal and adjusting. Midway through, they discover one item is larger than expected. Rather than abandoning the goal, they talk with the Product Owner and renegotiate scope within the Sprint, as the Guide allows. At the Sprint Review, stakeholders try the new flow and suggest changes, and the backlog is updated. At the retrospective, the team agrees to pair on payment code next time because knowledge of it sat with one person.

Common Pitfalls

A few patterns show up often when Scrum struggles:

• Treating the Sprint Review as a demo for approval rather than a working session.
• A Product Owner who is a proxy with no real authority over the backlog.
• Counting work as done when it does not meet the Definition of Done.
• Running every event as a status report to a manager instead of a team-owned inspection.
• Skipping retrospectives when the team is busy, which removes the main mechanism for improvement.

Key takeaways

• The current Scrum Guide is the November 2020 edition by Ken Schwaber and Jeff Sutherland, free at scrumguides.org.
• Scrum is a lightweight framework built on empiricism and lean thinking, with three pillars and five values.
• The Scrum Team has three accountabilities: Developers, Product Owner and Scrum Master, typically 10 or fewer people in total.
• There are five events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective) and three artifacts, each with a commitment.
• Practices such as story points and user stories are optional additions, not part of Scrum itself.

Sources

• The 2020 Scrum Guide
• Scrum Guides home page
• Scrum Guide Revision History