Scrum Guide (LeSS Version)

Download the PDF

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.