This is my unofficial summary of the official Scrum Guide. This page is intended as a reference, not an endorsement.
The Scrum Guide was first published in 2010. It defines core Scrum: "Scrum and X" is still Scrum, but "Scrum without X" is not, and may limit or even remove the benefits of Scrum.
Scrum is a process that tries to make work predictable and safe. It reveals inefficiencies and problems, so you can adjust.
Scrum encourages small flat teams, focused on on Product Goal. The team should collectively have all the skills they need. They should be self-managing and work at a sustainable pace. They should create value each Sprint.
Developers create a usable Increment each Sprint. They:
The Product Owner maximizes the value of the product. The Product Owner is one person, representing all stakeholders, with complete control over the Product Backlog - although they may delegate. They:
The Scrum Master makes sure you're Doing Scrum per this Guide.
For the Scrum Team, they:
For the Product Owner, they:
For the organization, they:
The events of Scrum enable the pillars. They create regularity and minimize the need for other meetings. They should be held at consistent times and places.
The core event is the Sprint, which contains the other events. Sprints take place back-to-back. They are the same length every time. A Sprint more than a month long would allow invalidation of goals, higher complexity, and more risk. Each Sprint may be considered a short project.
During the Sprint:
If the Sprint's goal becomes obsolete, the Product Owner may cancel the Sprint.
The Scrum Guide does not endorse burn-downs, burn-ups, or cumulative flows. They are useful, but only what has already happened may be used for forward-looking decision making: Empiricism.
In this meeting, the team lays out a plan for the Sprint. They discuss:
This meeting is held at the same time and place every day. In it, the team checks their progress against the Sprint's goal. Daily Scrums improve communications, identify impediments, promote quick decision-making, and may eliminate the need for other meetings.
In this meeting, the team presents their work to stakeholders. Attendees collaborate on what to do next. The backlog may be adjusted to meet new opportunities. The Sprint Review is a working session, not just a presentation.
In this meeting, the team inspects how the last Sprint went. Assumptions that led them astray are identified and their origins explored. The team discusses what went well, what problems came up, and how they were solved (or not solved). The team should identify and implement the most impactful changes as soon as possible.
Scrum’s artifacts are transparent representions of work or value. Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Product Backlog items that can be Done by the Scrum Team within one Sprint are ready for Sprint Planning. Backlog items are refined by:
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
The Product Goal describes a future state of the product. It is the long-term objective for the team. There can be only one at a time. The backlog emerges to define what will fulfill the Product Goal.
A product has a clear boundary, known stakeholders, and well-defined users or customers.
The Developers plan what will be done in the Sprint, why, and how. The plan is a highly visible, real-time picture of the work. It is inspected during the Daily Scrum.
During Sprint Planning, the Developers commit to a single objective for the Sprint. Developers should focus on the goal together, rather than on separate initiatives. The goal should be flexible in exactly how it's acheived; if it turns out to be more work than expected, Developers negotiate the scope of the Sprint plan with the Product Owner, without affecting the Sprint Goal.
An Increment is a concrete, verified, usable step toward the Product Goal. Each Increment is additive to all prior Increments. Multiple Increments may be created within a Sprint, and they will all be presented at the Sprint Review. Increments may be delivered prior to the end of the Sprint; the Sprint Review is not a gate.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
The Definition of Done describes the state and quality of a completed backlog item. Whenever an item is Done, an Increment is born. If an item is not Done, it cannot be released or presented at the Sprint Review. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
The Scrum Team must follow the organization's Definition of Done as a minimum, if it exists. If not, the team creates one. If multiple teams work on a product, they collaborate to create a shared Definition of Done.
This summary of Scrum was written by Ben Martin in 2021. While he made every effort to preserve intent while cutting word count in half, such edits go explicitly against the unaltered Scrum Guide, which says:
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Scrum was developed by Ken Schwaber and Jeff Sutherland in the early 1990s, and first presented at the OOPSLA conference in 1995. Special credit also goes to Jeff McKenna, John Scumniotales, Mike Smith, and Chris Martin.
© 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.