The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game 敏捷指导手册

Ken Schwaber & Jeff Sutherland
The Scrum Guide
The Definitive Guide to Scrum: The Rules of the Game
November 2020 1

Purpose of the Scrum Guide
We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it.

The Scrum Guide contains the definition of Scrum. 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.

We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.

As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.

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. 2

Purpose of the Scrum Guide … 1
Scrum Definition … 3
Scrum Theory … 3
Transparency … 3
Inspection … 4
Adaptation … 4
Scrum Values … 4
Scrum Team … 5
Developers … 5
Product Owner … 5
Scrum Master … 6
Scrum Events … 7
The Sprint … 7
Sprint Planning … 8
Daily Scrum … 9
Sprint Review … 9
Sprint Retrospective … 10
Scrum Artifacts… 10
Product Backlog … 10
Commitment: Product Goal … 11
Sprint Backlog … 11
Commitment: Sprint Goal … 11
Increment… 11
Commitment: Definition of Done … 12
End Note … 13
Acknowledgements … 13
People … 13
Scrum Guide History … 13 3

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:
简言之，敏捷需要敏捷主管促成这样一个环境：

1. A Product Owner orders the work for a complex problem into a Product Backlog.
   产品经理将解决复杂的问题的工作排列在产品待办事项中
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
   敏捷团队在每个Sprint中，将分配的工作转换为增量价值
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
   敏捷团队和干系人检阅开发结果，调整安排下一个Sprint的工作安排
4. Repeat
   重复

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.
敏捷是简单的。

Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary.

Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that 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. Scrum 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 empirical Scrum pillars of transparency, inspection, and adaptation.
敏捷在一个容器活动中结合了四种用于检阅和调整的活动，即 Sprint。因为这些活动实现了经验敏捷的高透明性，高检阅能力，高适应性。

Transparency
The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk. 4
紧急的程序和工作必须对执行工作的人和接收工作的人透明。在敏捷中，重要的决定要基于三个人工制品的可见的状态。透明性差的制品会减少价值，增加风险。

Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection
The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of 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 being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
任何敏捷过程脱离可接收的界限或者产生的结果是不可接收的，这进行的进程或者产出额材料都必须做出纠正。纠正必须快，以最大限度降低进一步的脱轨。

Adaptation becomes more difficult when the people involved 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

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges.
敏捷致力于实现目标且互相支持。主要的目的是完成Sprint中的工作，以及向目标迈进。敏捷团队和干系人对工作和挑战是包容开放的。

Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.
敏捷团队成员都认为对方是有能力的，独立的，与他们工作的人也是这样认为他们的。成员有勇气去做正确的事情，解决疑难杂症。

These values give direction to the Scrum Team with regard to their 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.
敏捷价值可以知道团队人员的工作，行动，和行为。团队做的决定，采取的步骤和敏捷使用的方法应该增强价值，而不是降低或者破坏价值。

The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust. 5
敏捷团队成员学习探索敏捷活动和成品中的价值。当团队和工作人员让这些价值得以体现，经验敏捷柱，如 透明柱，检阅柱，适应柱达到 生命创造信用级别。

Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, 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, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
敏捷团队是一组专业人员，他们同时专注于同一个目标，即产品目标。敏捷团队是跨功能的，即成员拥有所有需要的技术以在每个Sprint中创造价值。他们自主管理，即他们内部决定谁做什么，什么时候做，怎么做。

The Scrum 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.
敏捷团队足以小以保持敏捷，足以大以完成Sprint内的重要工作，典型的 10个或者更少的人。总的来说，我们发现团队越小沟通更好，更加有产出。

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
如果敏捷团队太大了，他们应该考证重组成多个敏捷的小团队，每个团队专注于同一个产品。因此，他们应该拥有同样的产品目标，产品待办事项，产品负责人。

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.
敏捷团队负责所有的来自于干系人合作，验证，维护，合作，实验，研究和开发等其他需要的行为中与产品相关的活动。机构组织赋能这些活动以管理他们自己的工作。

Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
在Sprints中以可以持续的速度工作，可以提高团队的专注程度和协调性。每个Sprint，整个团队都能够创造有价值的，有用的增量价值。敏捷定义了三个具体的职责岗位：开发，产品负责人，敏捷主管。

Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work.
开发们致力于在每一个Sprint中创造任何一个可用的价值增量；他们需要多元的技术，工作不同，所需技术也会不同。

However, the Developers 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.
开发的负责范围：
制定 Sprint 计划, Sprint 待办事项
以完成标准提供质量
每天根据Sprint目标调整计划
展现各自的专业性

Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
项目负责人负责最大化团队完成的项目成果的价值。随组织，团队，成员的不同，如何做到这点也是大有不同的

The Product Owner is also accountable for effective Product Backlog management, which includes:
● Developing and explicitly communicating the Product Goal;
● Creating and clearly communicating Product Backlog items;
● Ordering Product Backlog items; and,
● Ensuring that the Product Backlog is transparent, visible 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 visible 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 accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

敏捷负责人负责根据手册建立敏捷团队。他通过帮助敏捷团队内的和机构内的成员理解敏捷原理和实例来建立团队。

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
敏捷主管负责团队的效益。为此，他需要在敏捷架构内提高团队实战。

The Scrum Master serves the Scrum Team in several ways, including:
● Coaching the team members in self-management and cross-functionality;
● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
● Causing the removal of impediments to the Scrum 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 Goal definition and Product Backlog management;
● Helping the Scrum 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 implementations within the organization;
● Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
● Removing barriers between stakeholders and Scrum Teams.
敏捷主管在不同方面服务于团体，包括：
领导，培训和指导团体适应敏捷
规划和建议敏捷实施
帮助员工和干系人理解和实施有实战性的方法来完成复杂的工作
排除干系人和敏捷团队间的阻碍

Scrum Events
The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required.
Sprint 是其他活动的容器。每个活动都是一个检阅，适应敏捷成品的机会。这些活动都是为了需要的透明而设置。

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.
活动发展不成功会导致失去检阅和调整的机会。这些活动会形成规律工作，最少话不需要的会议。最好，所有的活动都在同一个时间和地点举行，以减少麻烦。

The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints 是敏捷的心跳，在这里想法被转化为价值。它们是固定长度的活动，一个月或者更少，以创造协团队协调性。前一个Sprint结束后会立即开始一个新的Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
所有为了完成产品目标，比如: Sprint 计划，每日敏捷活动，Sprint 检阅，回省等所作的工作，都发生在Sprints当中。
During the Sprint:
● No changes are made that would 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.
在Sprint期间：
不能发生危及Sprint 目标的改动
质量不能降低
产品代办事项可以按需重定义
产品责任人知晓的情况下可以重新讨论工作范围

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. 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.
为了项目目标而保证检阅和进度调整，这样 Sprints 可以预见不确定性。当Sprint范围太长，Sprint 目标可能无效，会出现复杂性，增加风险。可以采取更短的Sprints以产生更多的学习机会，将风险和努力限制到更少的时间架构里面。每个Sprint 可以认为是一个小的项目。

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these 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 could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
只有已经发生过的才可能被用于制定前瞻性决定。如果Sprint 目标过时，Sprint 可能被取消。只有项目责任人有权去取消Sprint。

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 entire Scrum Team.
Sprint 计划罗列出Sprint中需要做的工作，以此触发Sprint。这个结果是整个团队协作的结果。

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
项目责任人确保参与者能为讨论重要的项目待办事项以及它们对应的项目目标而准备好。团队也可以邀请其他人来参与提出建议。

Sprint Planning addresses the following topics:
Sprint 计划解决以下论题：

Topic One: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
项目责任人处理产品如何增加当前Sprint的价值和效用。整个团队协作定义Sprint目标并且交流为什么对干系人是有价值的。Sprint 目标必须优先于Sprint 计划结束前被定版。

Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
与产品责任人讨论后，开发要从产品代办事项中选择当前Sprint的事项。团队可能纠正这些事项，以便提高理解程度和信任。
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
选择一个Sprint中能完成多少事项或许是有挑战的。但是，开发了解过去的表现，能力，完成定律越多，他们就能在Sprint预测中更加自信。

Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
每个选定的产品待办事项，开发规划需要的工作来创造满足完成定律的工作增量。这通常是通过将产品待办事项拆分为一天或者更少时间的工作项。这是通过开发的自我判断来完成的。其他任何人没法告诉他们要怎样把产品待办事项拆分为价值增量。

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.
Sprint 目标，被选中的产品待办事项，再加上为实现它们的Sprint 计划一起被成为 Sprint 待办事项。Sprint 计划的时间被限制为一个月的Sprint中的最多8小时。

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.
每日敏捷会议的目的是去检查工作进度，按需调整Sprint 待办事项，调整接下来的工作安排。

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
每日敏捷会议在15分钟内完成。为了减少麻烦，要在同一个地方和时间举行。如果产品责任人或者敏捷主管也工作在Sprint代办事项上面，他们也要作为开发人参与会议。

The Developers 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 day 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 other meetings.
每日敏捷会议提高了交流，鉴别了困难，促进快速制定决定，且消除了多余的其他会议。

The Daily Scrum is not the only time Developers are 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中的剩余工作。
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
Sprint 检阅的目的是检查Sprint的产出，决定接下的调整。团队向重要的干系人展示工作所成，并且讨论为完成项目目标所完成的进度。

During the event, the Scrum Team 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.
在Sprint 检阅中，团队和干系人会查看sprint中完成的内容以及环境中所发生的改变。基于这些信息，参与者要协调接下来的工作。产品待办事项也可能调整以满足新的机会。

The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
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 检阅是一个工作会议，团队应该避免仅仅限制于展示。它是Sprint的第二大活动，一个Sprint，限制在最长4个小时之内。对于更短的Sprint，这个活动时间通常会更短。

Sprint Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum 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.
Sprint 回顾的目的是制定计划来提高质量和效率。敏捷团队回顾上一个Sprint中的成员，交流，进程，工具和完成定律的进行情况。检查的内容随工作领域不同而变化。

Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum 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.

Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
● For the Product Backlog it is the Product Goal.
● For the Sprint Backlog it is the Sprint Goal.
● For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Product Backlog
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 deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

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.

Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

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 Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. 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.

Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. 12

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.

Commitment: Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

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.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams 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).
© 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.