Scrum Guide (LeSS Version)

Craig Larman & Bas Vodde (original by Ken Schwaber & Jeff Sutherland) July 2024

Purpose of the Scrum Guide

Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

Ken Schwaber and Jeff Sutherland lead the development of the Scrum framework.

LeSS (Large-Scale Scrum) is an organizational system that evolved as a result of applying Scrum to multi-team product development. LeSS is defined by the LeSS Rules. The LeSS rules assume Scrum structures within the teams and Scrum concepts on the whole product level (as defined in this guide).

Why this update to the Guide? The latest versions of Scrum and LeSS have evolved in parallel which has led to the assumed Scrum in Large-Scale Scrum being a combination of different Scrum versions, creating inconsistency, and potentially a more complicated and less adaptive organization in a multi-team situation.

This version of the Guide describes Scrum as assumed in LeSS. Craig Larman and Bas Vodde developed LeSS and this version of the Guide based on the Scrum Guide by Ken Schwaber.

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.

Scrum Definition

Scrum is a lightweight framework that helps organizations to productively and creatively deliver a product of the highest possible value that addresses complex adaptive problems.

In a nutshell, Scrum requires:

1. A Product Owner orders the ideas for incrementally creating a product.
2. The Team turns a selection of these ideas into a valuable product increment.
3. The Team, Product Owner and stakeholders together inspect the results and adjust for the next Sprint.
4. Repeat.

The Scrum framework is purposefully incomplete. It provides a shell that requires the collective intelligence of the people using it to fill it in. It makes transparent the relative efficacy of current management, environment, and work techniques, so that continuous improvement of the product, the team, and the working environment can happen.

Scrum is simple. Rather than provide people with detailed instructions, the rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

Scrum Theory

Scrum is founded on empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Scrum employs an iterative, incremental approach to optimize adaptiveness and to expose risks early.

Three pillars uphold empiricism: transparency, inspection, and adaptation.

Transparency

Scrum both enables and requires transparency. It enables transparency by defining inspect-adapt points. But it requires the emergent process and product to be transparent to those performing the work as well as those receiving the product. Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection

The progress and process must be inspected frequently and diligently to discover potential improvements and new opportunities to increase value delivery, adaptiveness, effectiveness, and work satisfaction. To help with inspection, Scrum provides cadence in the form of its four events.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation

If potential improvements or new opportunities are discovered then the process used and/or product produced can be adjusted. The adjustment must be made as soon as possible to maximize value delivery.

Adaptation becomes more difficult when the people involved are not empowered or self-managing.

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

The Team commits to continuously improving and to supporting each other. Their primary focus is on the work in the Sprint to make the best possible progress. The Team, Product Owner and its stakeholders are open about the work and the challenges. Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Team members have the courage to do the right thing, to work on tough problems.

These values give direction with regard to the work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. When these values are embodied by the Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

Scrum Roles

Scrum consists of a Scrum Master, a Product Owner, and a Team, all focused on the Product Vision.

The Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If the Team becomes too large, they should consider reorganizing into multiple cohesive teams, each focused on the same product. Therefore, they should share the same Product Vision, Product Backlog, and Product Owner.

The Team and Product Owner are responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required to create the Product. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves focus and consistency.

Team

The Team consists of the people that are committed to creating any aspect of a usable Product Increment each Sprint.

The Team has the following characteristics:

• The Team is self-managing, meaning they internally decide who does what, when, and how — they are responsible for monitoring and managing the process and progress.
• The Team is cross-functional, the Team members have or can acquire all the skills necessary to create a product Increment.
• The Team has no sub-teams related to topics such as testing, architecture, operations, UX or business analysis.
• The Team members may have specialized skills and areas of focus, but accountability belongs to the Team as a whole.
• The Team recognizes no responsibility-limiting titles or roles for Team members.

The specific skills needed by the Team members are often broad and will vary with the domain of work. However, the Team members are always responsible 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 responsible for maximizing the value of the product resulting from the work of the Team. How this is done may vary widely across organizations.
The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Vision;
• Adding Product Backlog items and clearly communicating how they achieve the Product Vision;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are transparent in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

Scrum Master

The Scrum Master is responsible for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice.

The Scrum Master is responsible for a well-functioning Team and Product Owner, and for the organization to understand Scrum and use it for the benefits of value delivery and adaptiveness. They do this by supporting improvement.

Scrum Masters are true leaders who serve the Team, Product Owner and the larger organization. The Scrum Master serves the Team in several ways, including:

• Coaching the Team members in self-management and cross-functionality;
• Helping the Team focus on creating high-value Increments that meet the Definition of Done;
• Causing the removal of impediments to the Team’s progress; and,
• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Vision definition and Product Backlog management;
• Helping the Product Owner and the Team understand the need for clear and concise Product Backlog Items;
• Helping establish empirical product planning for a complex environment; and,
• Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum adoptions within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and the Team and Product Owner.

The Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Vision, including Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective, and Product Backlog Refinement happen within Sprints.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• Scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprints create a rhythm and ensure inspection and adaptation of progress toward a Product Vision. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.

Various practices exist for forecasting progress. While forecasting is needed at times, the forecasting practices do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

A Sprint may be canceled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Scrum Events

Each event in Scrum is a formal opportunity to inspect and adapt. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Optimally, all events are held at the same time and place to reduce complexity.

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the Team and the Product Owner. Other people may be invited to attend Sprint Planning to provide advice.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they help to achieve the Product Vision.

Sprint Planning addresses the following topics:

Why is this Sprint valuable? — The Product Owner proposes how the product could increase its value and utility in the current Sprint. The Team and Product Owner then collaborate to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders and how it helps to achieve the Product Vision. The Sprint Goal must be finalized prior to the end of Sprint Planning.

What can be Done this Sprint? — Through discussion with the Product Owner, the Team selects items from the top of the Product Backlog to include in the current Sprint. The Team may refine these items during this process.

How will the chosen work get done? — For each selected Product Backlog item, the Team plans the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller tasks of one day or less. How this is done is at the sole discretion of the Team.

The Sprint Goal is the single objective for the Sprint. It provides flexibility in terms of the exact work needed to achieve it. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal. The Sprint Goal also creates coherence and focus, encouraging the Team to work together rather than on separate initiatives.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a maximum 15-minute event for the Team. To reduce complexity, it is held at the same time and place every working day of the Sprint.

The Team can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next 24 hours of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for some other meetings.

The Daily Scrum is not the only time the Team is allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Team and Product Owner presents the Product Increment to key stakeholders and progress toward the Product Vision is discussed.

During the event, the Team, Product Owner and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and just presentations should be avoided.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality, effectiveness and enjoyment.

The Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Product Backlog Refinement

The purpose of Product Backlog Refinement is to ensure the Product Backlog is well-maintained, prepared for Sprint Planning, and aligned with the Product Vision. Product Backlog Refinement is done as either an ongoing activity, part of Sprint Planning, or as a separate event during the Sprint.

During Product Backlog Refinement, the Product Owner reinforces the Product Vision. The Team and Product Owner, together with key stakeholders when required, will (1) clarify Product Backlog Items that are likely to be selected for the upcoming Sprints, (2) split Product Backlog Items that are too large and will be considered relatively soon, and (3) estimate the size of new Product Backlog Items or re-estimate existing ones, when required.

Product Backlog Refinement usually takes a maximum of 10% of the Sprint.

Scrum Artifacts

Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Product Backlog

The Product Backlog is an emergent, ordered list of Product Backlog Items, which describe whatever is needed to evolve the product. It is the single source of work undertaken by the Team.

A Product Backlog is never complete. It evolves as the product and the environment evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

Product Backlog Items may have the attributes such as description, size, and value. The Team is responsible for estimations. Product Backlog Items that the Team can pick up have usually been clarified during a previous Product Backlog Refinement.

Sprint Backlog

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog Items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Team. It is a highly transparent, real-time picture of the work that the Team plans to accomplish during the Sprint to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail so that they can inspect their progress in the Daily Scrum.

Increment

An Increment is the output of the Sprint and is a concrete stepping stone toward achieving the Product Vision. Each Increment is additive to all prior Increments and thoroughly verified. To provide value, the Increment must be usable.

Definition of Done

The Definition of Done is an agreement between the Product Owner and the Team on what is expected for a Product Backlog Item to be declared Done. It usually describes what quality criteria the Product Backlog Item needs to meet.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog Item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

The team members are required to conform to the Definition of Done. If multiple Teams are working together on a product, they must mutually define and comply with the same Definition of Done.

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.

Acknowledgements

People

Of the thousands of people who have contributed to Scrum, we should single out those who were instrumental at the start: Jeff Sutherland worked with Jeff McKenna and John Scumniotales, and Ken Schwaber worked with Mike Smith and Chris Martin, and all of them worked together. Many others contributed in the ensuing years and without their help Scrum would not be refined as it is today.

Scrum Guide History

Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in 1995. It essentially documented the learning that Ken and Jeff gained over the previous few years and made public the first formal definition of Scrum.

The Scrum Guide documents Scrum as developed, evolved, and sustained for 30-plus years by Jeff Sutherland and Ken Schwaber. Other sources provide patterns, processes, and insights that complement the Scrum framework. These may increase productivity, value, creativity, and satisfaction with the results.

The complete history of Scrum is described elsewhere. To honor the first places where it was tried and proven, we recognize Individual Inc., Newspage, Fidelity Investments, and IDX (now GE Medical).

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.

Adaptation Notice

This document is an adaptation of the original Scrum Guide by Ken Schwaber and Jeff Sutherland. Changes were made to the original document by Craig Larman and Bas Vodde in 2024, including minor edits and summaries of changes.

© 2024 Craig Larman and Bas Vodde

Summary of updates in LeSS version

This update to the Scrum Guide has the Scrum Guide 2020 as a basis, yet some parts have been taken from the Scrum Guide 2017 instead. The larger changes are:

• Re-introduced product instead of “work for complex problem.”
• Removed the Scrum Team concept.
• Renamed Developers to Team.
• Removed Sprint out of Events and made it a separate thing.
• Renamed Product Goal to Product Vision.
• Removed “creating and communicating Product Backlog Items” from Backlog Management in the Product Owner section.
• Removed Topic 1/2/3 terminology and just called it why/what/how.
• Added Product Backlog Refinement to the Scrum Events, yet mentioned that it can be done as an activity rather than an event.
• Removed the language of commitment to artifacts.
• Moved Sprint Goal in one place, inside Sprint Planning.
• Introduced Definition of Done, not as commitment but as an agreement.