‭Craig Larman & Bas Vodde‬‭(original by Ken Schwaber & Jeff Sutherland)‬‭The Scrum Guide‬‭(LeSS Version)‬‭July 2024‬

‭Purpose of the Scrum Guide‬‭ crum is a framework for developing, delivering, and sustaining complex products. This Guide‬S‭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.‬‭ eSS (Large-Scale Scrum) is an organizational system that evolved as a result of applying‬L‭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).‬‭ hy this update to the Guide? The latest versions of Scrum and LeSS have evolved in parallel‬W‭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.‬‭ his version of the Guide describes Scrum as assumed in LeSS. Craig Larman and Bas Vodde‬T‭developed LeSS and this version of the Guide based on the‬‭Scrum Guide‬‭by Ken Schwaber.‬‭ his publication is offered for license under the Attribution Share-Alike license of Creative‬
T‭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.‬‭1‬

‭Purpose of the Scrum Guide‬‭1‬‭Scrum Definition‬‭3‬‭Scrum Theory‬‭3‬‭Transparency‬‭3‬‭Inspection‬‭4‬‭Adaptation‬‭4‬‭Scrum Values‬‭4‬‭Scrum‬‭5‬‭Team‬‭5‬‭Product Owner‬‭6‬‭Scrum Master‬‭6‬‭The Sprint‬‭7‬‭Scrum Events‬‭8‬‭Sprint Planning‬‭8‬‭Daily Scrum‬‭9‬‭Sprint Review‬‭10‬‭Sprint Retrospective‬‭10‬‭Product Backlog Refinement‬‭10‬‭Scrum Artifacts‬‭11‬‭Product Backlog‬‭11‬‭Sprint Backlog‬‭11‬‭Increment‬‭12‬‭Definition of Done‬‭12‬‭End Note‬‭13‬‭Acknowledgements‬‭13‬‭People‬‭13‬‭Scrum Guide History‬‭13‬‭Summary of updates in LeSS version‬

‭14‬

‭2‬

‭Scrum Definition‬‭ crum is a lightweight framework that helps organizations to productively and creatively deliver‬S‭a product of the highest possible value that addresses complex adaptive problems.‬‭In a nutshell, Scrum requires:‬‭ .‬ ‭A Product Owner orders the ideas for incrementally creating a product.‬1‭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.‬‭ he Scrum framework is purposefully incomplete. It provides a shell that requires the collective‬T‭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.‬‭ crum is simple. Rather than provide people with detailed instructions, the rules of Scrum bind‬S‭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‬‭ crum is founded on empiricism. Empiricism asserts that knowledge comes from experience‬S‭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‬‭ crum both enables and requires transparency. It enables transparency by defining‬S‭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.‬‭3‬

‭Inspection‬‭ he progress and process must be inspected frequently and diligently to discover potential‬
T‭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.‬
I‭nspection enables adaptation. Inspection without adaptation is considered pointless. Scrum‬‭events are designed to provoke change.‬‭Adaptation‬I‭f 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.‬‭ daptation becomes more difficult when the people involved are not empowered or‬A‭self-managing.‬‭Scrum Values‬‭Successful use of Scrum depends on people becoming more proficient in living five values:‬‭Commitment, Focus, Openness, Respect, and Courage‬‭ he Team commits to continuously improving and to supporting each other. Their primary‬T‭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.‬‭ hese values give direction with regard to the work, actions, and behavior. The decisions that‬T‭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.‬‭4‬‭Scrum Roles‬‭ crum consists of a Scrum Master, a Product Owner, and a Team, all focused on the Product‬
S‭Vision.‬‭ he Team is small enough to remain nimble and large enough to complete significant work‬T‭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.‬‭ he Team and Product Owner are responsible for all product-related activities from stakeholder‬T‭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‬‭ he Team consists of the people that are committed to creating any aspect of a usable Product‬
T‭Increment each Sprint.‬‭The Team has the following characteristics:‬‭●‬ T‭ he 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.‬‭ he specific skills needed by the Team members are often broad and will vary with the domain‬T‭of work. However, the Team members are always responsible for:‬‭‬ C●‭ reating 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,‬‭5‬‭●‬ ‭Holding each other accountable as professionals.‬‭Product Owner‬‭ he Product Owner is responsible for maximizing the value of the product resulting from the‬T
‭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:‬‭‬ D●‭ eveloping 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.‬‭ he Product Owner may do the above work or may delegate the responsibility to others.‬
T‭Regardless, the Product Owner remains accountable.‬‭ or Product Owners to succeed, the entire organization must respect their decisions. These‬F‭decisions are transparent in the content and ordering of the Product Backlog, and through the‬‭inspectable Increment at the Sprint Review.‬‭ he Product Owner is one person, not a committee. The Product Owner may represent the‬T‭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‬‭ he Scrum Master is responsible for establishing Scrum as defined in the Scrum Guide. They‬T‭do this by helping everyone understand Scrum theory and practice.‬‭ he Scrum Master is responsible for a well-functioning Team and Product Owner, and for the‬T‭organization to understand Scrum and use it for the benefits of value delivery and‬‭adaptiveness. They do this by supporting improvement.‬‭ crum Masters are true leaders who serve the Team, Product Owner and the larger‬
S‭organization. The Scrum Master serves the Team in several ways, including:‬‭●‬ ‭Coaching the Team members in self-management and cross-functionality;‬‭6‬‭●‬ H‭ elping 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:‬‭●‬ H‭ elping 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:‬‭‬ L●‭ eading, 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‬‭ prints are the heartbeat of Scrum, where ideas are turned into value.‬S‭They are fixed length of one month or less to create consistency. A new Sprint starts‬‭immediately after the conclusion of the previous Sprint.‬‭ ll the work necessary to achieve the Product Vision, including Sprint Planning, Daily Scrums,‬
A‭Sprint Review, Sprint Retrospective, and Product Backlog Refinement happen within Sprints.‬‭During the Sprint:‬‭‬ N●‭ o 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.‬‭7‬‭ prints create a rhythm and ensure inspection and adaptation of progress toward a Product‬
S‭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.‬‭ arious practices exist for forecasting progress. While forecasting is needed at times, the‬V
‭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.‬‭ Sprint may be canceled if the Sprint Goal becomes obsolete. Only the Product Owner has‬A‭the authority to cancel the Sprint.‬‭Scrum Events‬‭ ach event in Scrum is a formal opportunity to inspect and adapt. These events are specifically‬E‭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‬‭ print Planning initiates the Sprint by laying out the work to be performed for the Sprint. This‬S‭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.‬‭ he Product Owner ensures that attendees are prepared to discuss the most important‬
T‭Product Backlog items and how they help to achieve the Product Vision.‬‭Sprint Planning addresses the following topics:‬‭ hy is this Sprint valuable?‬‭— The Product Owner proposes‬‭how the product could increase‬W‭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.‬‭8‬‭ hat can be Done this Sprint?‬ ‭— Through discussion with the Product Owner, the Team‬W‭selects items from the top of the Product Backlog to include in the current Sprint. The Team‬‭may refine these items during this process.‬‭ ow will the chosen work get done?‬‭— For each selected‬‭Product Backlog item, the Team‬H‭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.‬‭ he Sprint Goal is the single objective for the Sprint. It provides flexibility in terms of the exact‬
T‭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.‬‭ he Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering‬T‭them are together referred to as the Sprint Backlog.‬‭ print Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter‬S‭Sprints, the event is usually shorter.‬‭Daily Scrum‬‭ he purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the‬T
‭Sprint Backlog as necessary, adjusting the upcoming planned work.‬‭ he Daily Scrum is a maximum 15-minute event for the Team. To reduce complexity, it is held‬T‭at the same time and place every working day of the Sprint.‬‭ he Team can select whatever structure and techniques they want, as long as their Daily Scrum‬T‭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.‬‭ aily Scrums improve communications, identify impediments, promote quick decision-making,‬D‭and consequently eliminate the need for some other meetings.‬‭ he Daily Scrum is not the only time the Team is allowed to adjust their plan. They often meet‬T‭throughout the day for more detailed discussions about adapting or re-planning the rest of the‬‭Sprint’s work.‬‭9‬‭Sprint Review‬‭ he purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future‬T‭adaptations. The Team and Product Owner presents the Product Increment to key stakeholders‬‭and progress toward the Product Vision is discussed.‬‭ uring the event, the Team, Product Owner and stakeholders review what was accomplished in‬D‭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.‬‭ he Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of‬T‭four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.‬‭Sprint Retrospective‬‭ he purpose of the Sprint Retrospective is to plan ways to increase quality, effectiveness and‬T
‭enjoyment.‬‭ he Team inspects how the last Sprint went with regards to individuals, interactions,‬
T‭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.‬‭ he Team identifies the most helpful changes to improve its effectiveness. The most impactful‬T‭improvements are addressed as soon as possible. They may even be added to the Sprint‬‭Backlog for the next Sprint.‬‭ he Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for‬T
‭a one-month Sprint. For shorter Sprints, the event is usually shorter.‬‭Product Backlog Refinement‬‭ he purpose of Product Backlog Refinement is to ensure the Product Backlog is‬T‭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.‬‭10‬

‭ uring Product Backlog Refinement, the Product Owner reinforces the Product Vision. The‬
D
‭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‬‭ rtifacts defined by Scrum are specifically designed to maximize transparency of key‬A
‭information so that everybody has the same understanding of the artifact.‬‭Product Backlog‬‭ he Product Backlog is an emergent, ordered list of Product Backlog Items, which describe‬T‭whatever is needed to evolve the product. It is the single source of work undertaken by the‬‭Team.‬‭ Product Backlog is never complete. It evolves as the product and the environment evolves.‬
A‭The Product Backlog is dynamic; it constantly changes to identify what the product needs to‬‭be appropriate, competitive, and useful.‬‭ roduct Backlog Items may have the attributes such as description, size, and value. The Team‬P‭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‬‭ he Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog Items‬T‭selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).‬‭ he Sprint Backlog is a plan by and for the Team. It is a highly transparent, real-time picture of‬T‭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.‬‭11‬‭Increment‬‭ n Increment is the output of the Sprint and is a concrete stepping stone toward achieving the‬A
‭Product Vision. Each Increment is additive to all prior Increments and thoroughly verified. To‬‭provide value, the Increment must be usable.‬‭Definition of Done‬‭ he Definition of Done is an agreement between the Product Owner and the Team on what is‬T‭expected for a Product Backlog Item to be declared Done. It usually describes what quality‬‭criteria the Product Backlog Item needs to meet.‬‭ he Definition of Done creates transparency by providing everyone a shared understanding of‬T‭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.‬‭ he team members are required to conform to the Definition of Done. If multiple Teams are‬T
‭working together on a product, they must mutually define and comply with the same Definition‬‭of Done.‬‭12‬‭End Note‬‭ crum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable.‬
S‭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‬‭ f the thousands of people who have contributed to Scrum, we should single out those who‬O
‭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‬‭ en Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in‬K‭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.‬‭ he Scrum Guide documents Scrum as developed, evolved, and sustained for 30-plus years‬
T‭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.‬‭ he complete history of Scrum is described elsewhere. To honor the first places where it was‬T
‭tried and proven, we recognize Individual Inc., Newspage, Fidelity Investments, and IDX (now‬‭GE Medical).‬‭© 2020 Ken Schwaber and Jeff Sutherland‬‭ his publication is offered for license under the Attribution Share-Alike license of Creative‬
T‭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.‬‭13‬

‭Adaptation Notice‬‭ his document is an adaptation of the original Scrum Guide by Ken Schwaber and Jeff‬T‭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‬‭ his update to the Scrum Guide has the Scrum Guide 2020 as a basis, yet some parts have‬T‭been taken from the Scrum Guide 2017 instead. The larger changes are:‬
‭‬
●
‭●‬
‭●‬
‭●‬
‭●‬
‭●‬
‭‬
●
‭●‬
‭‬
●
‭●‬
‭●‬

‭ e-introduced product instead of “work for complex problem.”‬R‭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.‬‭14‬