The Scrum Guide
November 2020 · Schwaber & SutherlandPurpose of the Scrum Guide
Scrum was developed in the early 1990s by Ken Schwaber and Jeff Sutherland. The first version of the Scrum Guide was written in 2010 to help people worldwide understand Scrum, and has evolved through small, functional updates since then.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose essential to the overall value and results realized with Scrum. Changing the core design, leaving out elements, or not following the rules covers up problems and limits benefits — potentially rendering it useless.
Scrum is now adopted far beyond software product development. Developers, researchers, analysts, scientists, and other specialists use it. The word "developers" is used not to exclude, but to simplify — if you get value from Scrum, consider yourself included.
Scrum Definition
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The framework is purposefully incomplete, only defining the parts required to implement Scrum theory. It is built upon by the collective intelligence of the people using it.
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary, making visible the relative efficacy of current management, environment, and work techniques so improvements can be made.
Scrum Theory
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. It engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.
Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the three empirical pillars:
Transparency
The emergent process and work must be visible to those performing and receiving the work. Important decisions are based on the perceived state of the three formal artifacts. Low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection — inspection without transparency is misleading and wasteful.
Inspection
Scrum artifacts and progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. Scrum provides cadence through its five events. Inspection enables adaptation — inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
Adaptation
If any aspects of a process deviate outside acceptable limits, or if the resulting product is unacceptable, the process or materials must be adjusted as soon as possible to minimize further deviation. Adaptation becomes more difficult when people are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
Scrum Values
Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.
These values give direction to the Scrum Team with regard to their work, actions, and behavior. When these values are embodied by the Scrum Team and the people they work with, the empirical pillars of transparency, inspection, and adaptation come to life — building trust.
Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. It consists of one Scrum Master, one Product Owner, and Developers. There are no sub-teams or hierarchies — it is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional (members have all the skills necessary to create value each Sprint) and self-managing (they internally decide who does what, when, and how). The team is typically 10 or fewer people. Smaller teams communicate better and are more productive.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities:
Developers
Developers are committed to creating any aspect of a usable Increment each Sprint. They are always accountable for: creating a plan for the Sprint (the Sprint Backlog); instilling quality by adhering to a Definition of Done; adapting their plan each day toward the Sprint Goal; and holding each other accountable as professionals.
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are responsible for effective Product Backlog management, including: developing and communicating the Product Goal; creating and communicating Product Backlog items; ordering Product Backlog items; and ensuring the Product Backlog is transparent, visible, and understood. The Product Owner is one person, not a committee.
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, and for the Scrum Team's effectiveness. Scrum Masters are true leaders who serve the Scrum Team and the larger organization. They serve the team by coaching self-management and cross-functionality, helping focus on high-value Increments, causing removal of impediments, and ensuring events are positive and productive. They serve the Product Owner through techniques for Product Goal definition and backlog management. They serve the organization by leading Scrum adoption and removing barriers between stakeholders and teams.
Scrum Events
The Sprint is a container for all other events. Each event is a formal opportunity to inspect and adapt Scrum artifacts, designed to enable the transparency required. Events create regularity and minimize the need for meetings not defined in Scrum. Optimally, all events are held at the same time and place.
The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed-length events of one month or less. A new Sprint starts immediately after the previous one concludes. During the Sprint: no changes endanger the Sprint Goal; quality does not decrease; the Product Backlog is refined as needed; and scope may be clarified and renegotiated with the Product Owner as more is learned. Only the Product Owner has authority to cancel a Sprint.
Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed. It addresses three topics — Why: the team collaborates to define a Sprint Goal communicating value to stakeholders. What: Developers select items from the Product Backlog. How: Developers plan the work necessary to create an Increment meeting the Definition of Done, often decomposing items into work items of one day or less. Timeboxed to a maximum of eight hours for a one-month Sprint.
Daily Scrum
A 15-minute event for the Developers, held at the same time and place every working day. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The Developers can select whatever structure and techniques they want, as long as it focuses on the Sprint Goal and produces an actionable plan for the next day. It is not the only time Developers may adjust their plan.
Sprint Review
The Scrum Team presents results to key stakeholders and progress toward the Product Goal is discussed. Attendees collaborate on what to do next, and the Product Backlog may be adjusted to meet new opportunities. This is a working session — the team should avoid limiting it to a presentation. Timeboxed to a maximum of four hours for a one-month Sprint.
Sprint Retrospective
The purpose is to plan ways to increase quality and effectiveness. The team inspects how the last Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done. The most impactful improvements are addressed as soon as possible and may be added to the Sprint Backlog for the next Sprint. The Retrospective concludes the Sprint. Timeboxed to a maximum of three hours for a one-month Sprint.
Scrum Artifacts
Scrum's artifacts represent work or value. They are designed to maximize transparency of key information so everyone inspecting them has the same basis for adaptation. Each artifact contains a commitment to enhance transparency and focus against which progress can be measured.
Product Backlog → Commitment: Product Goal
The Product Backlog is an emergent, ordered list of what is needed to improve the product — the single source of work undertaken by the Scrum Team. Product Backlog refinement is the ongoing act of breaking down and further defining items into smaller, more precise items. Its commitment is the Product Goal: a future state of the product serving as a target for planning. The team must fulfill (or abandon) one objective before taking on the next.
Sprint Backlog → Commitment: Sprint Goal
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). It is a plan by and for the Developers — a highly visible, real-time picture of work, updated throughout the Sprint. The Sprint Goal is the single objective for the Sprint, providing flexibility in the exact work needed while creating coherence and focus.
Increment → Commitment: Definition of Done
An Increment is a concrete stepping stone toward the Product Goal. Each is additive to all prior Increments and thoroughly verified. Multiple Increments may be created within a Sprint and may be delivered before the Sprint ends. Work cannot be considered part of an Increment unless it meets the Definition of Done — a formal description of the state of the Increment when it meets quality measures required for the product. If a Product Backlog item doesn't meet the Definition of Done, it cannot be released or presented at the Sprint Review.
End Note
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.
Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in 1995. The Scrum Guide documents Scrum as developed, evolved, and sustained for 30-plus years. Other sources provide patterns, processes, and insights that complement the framework.
© 2020 Ken Schwaber and Jeff Sutherland. Offered under the Attribution Share-Alike license of Creative Commons (CC BY-SA 4.0).