来源 https://www.scrum.org/resources/scrum-guide⌗

本文改自一篇繁体 scrum 指南⌗

Scrum 指南的目的

我们在 1990 年代初期开发出 Scrum。为了协助全世界的人们了解 Scrum，我们于 2010 年间撰写了 Scrum 指南的首版。自那时起，我们透过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。

Scrum 指南包含了 Scrum 的定义。为了实现 Scrum 中的全部价值和成果，框架内的各种元素都具有其特定用途。改变 Scrum 的核心设计或 Scrum 的各种理念，遗漏其中任何元素，或是不遵照 Scrum 的规则，是在掩盖问题，并限制了 Scrum 的各种好处，甚至可能使其变得毫无用处。

我们关注到 Scrum 在错综复杂（complex）的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上错综复杂（complex）的工作领域中被采用，超越了原本 Scrum 的起源领域 – 软体产品开发。随着 Scrum 的应用范围逐渐扩大，developers、研究人员、分析师、科学家与其他专家都能以其工作。我们在 Scrum 中使用 「developers」 一词不是为了排除其他使用者，而是为了简化统称。如果您从 Scrum 当中获得价值，那么您可以将自己视为其中一员。

在使用 Scrum 时，可能可以找到、应用和设计符合本文所描述的 Scrum 框架内的模式、流程、见解等。它们的描述超出了本指南的宗旨，因为其中的差异跟您的 Scrum 使用环境有关。这些使用 Scrum 框架内的战术技巧有很大的变化，因此不在此描述。

Ken Schwaber & Jeff Sutherland 2020 年 11 月

Scrum 的定义⌗

Scrum 是一个轻量化的框架，透过提供针对错综复杂（complex）问题的调适性解决方案，来帮助人们、团队与组织产生价值。 简而言之，Scrum 需要一位 Scrum Master 来营造一个环境：

  1. 由一位 Product Owner 将错综复杂（complex）问题所需之工作事项整理排列成为一份 Product Backlog；
  2. Scrum Team 在一个 Sprint 中将所挑选的工作转化为价值的 Increment；
  3. Scrum Team 和利害关系人（stakeholders）检视结果，并为下一个 Sprint 进行调整；
  4. 重复。

Scrum 是易于理解的，试着原封不动地应用它，然后看看 Scrum 的哲学、理论与架构是否可以帮助你达到目标与创造价值。我们刻意的让 Scrum 框架留白、不完整，而只定义了实践 Scrum 理论时所需要的部分，Scrum 是建立在 Scrum 使用者的群体智慧之上的， Scrum 指南的规则提供的是对这些人之间各种关系与互动的指引，而不是给予详细的使用说明。

在 Scrum 框架中可以使用各种不同的流程、技术，与方法。 Scrum 将现行的实务做法包装进来，或是使其变成非必要的。 Scrum 凸显当下关于管理、环境和各种工作技术的相对成效，以便可以对其进行改善。

Scrum 的理论⌗

Scrum 建立在经验主义（empiricism）和精实思维（lean thinking）之上。经验主义（empiricism）坚信，知识来自经验，以及根据观察到的事物做出决策。精实思维（lean thinking）减少浪费，专注于根本。

Scrum 采行迭代（iterative）和增量（incremental）方法来优化对未来的预测性并控制风险。Scrum 让一群共同拥有所有技能和专长的人员参与来完成工作，并根据需要来分享或获取所需技能。

Scrum 有四个正式检视与调适的事件，并且用另外一个事件：Sprint 来包含这四个事件。这些事件起作用的原因是它们实现了以经验为导向的 Scrum 支柱：透明性、检视性与调适性。

透明性（Transparency）⌗

涌现的（Emergent）流程和工作必须对执行工作和接受工作的人员都是可见的。在 Scrum 里，重要的决策是基于对其三个正式 artifacts 的感知状态。透明性低的 artifacts 会导致做出让价值减少且风险增加的决策。

透明性促成检视性。没有透明性的检视会产生误导和浪费。

检视性（Inspection）⌗

必须要经常用心地检视 Scrum 的 artifacts 与一致同意的目标进度，以便发现潜在的误差和问题。为了有助于检视性，Scrum 以五个事件的形式提供了稳定的节奏。

检视性促成调适性。没有调适性的检视是没有意义的。 Scrum 的事件旨在激发改变。

调适性（Adaptation）⌗

若是流程的任何方面已偏离且超出可接受的范围，或是所得的产品无法被接受，则必须将所采用的流程或其打造出来的材料进行调整。调整工作必须尽快执行，以减少未来更多的偏差。

当相关人员未获得授权，或无法自我管理（self-managing）时，调适性将变得更加艰难。一个 Scrum Team 透过检视而学习到的新事物之当下，应当立刻调适。

Scrum 的价值观⌗

Scrum 的成功应用取决于人们更完善地活出这五项价值观：

承诺、专注、开放、尊重、勇气⌗

Scrum Team 致力于达成其目标并彼此相互支援。他们主要专注在 Sprint 的工作，尽可能地朝向目标前进，以获取最好的进展。 Scrum Team 与其利害关系人（stakeholders）对于工作及挑战抱持着开放的态度。 Scrum Team 的成员们互相尊重对方是个有能力和独立的人，同时也受其他同事同等的尊重。 Scrum Team 的成员们有勇气去做对的事情、并处理棘手的问题。

这些价值观指引了 Scrum Team 的工作、行动与行为。所做出的决定、所采取的步骤与如何使用 Scrum 都应该反覆的加强这些价值观，而不是削弱或破坏这些价值观。 Scrum Team 成员们依照 Scrum 的事件和 artifacts 来学习并探索这些价值观。当 Scrum Team 以及与工作的同事们展现了这些价值观，就能活现出 Scrum 经验的支柱：透明性、检视性与调适性，并在每个人之间建立信任。

Scrum Team⌗

Scrum 以小团队作为基本单位，称为 Scrum Team。 Scrum Team 由一名 Scrum Master、一名 Product Owner 与 Developers 所组成。在 Scrum Team 内没有子团队或是阶级架构，是由一群具有凝聚力的专业人士，一次只专注在一个目标上：Product Goal。

Scrum Teams 是跨职能（cross-functional）的，也就是说，成员们拥有在 Sprint 内创造价值所需的所有技能。他们也是自我管理（self-managing）的，也就是说，他们在团队内部决定谁做什么、何时做以及如何做。

Scrum Team 规模足够小以保持灵活性，同时足够大以便可以在 Sprint 内完成重要的工作，通常人数在 10 人以下。一般而言，我们发现越小的团队沟通越好，生产力更高。如果 Scrum Teams 变得太大，他们应该考虑重新组织为多个有凝聚力的 Scrum Team，每个团队还是专注在同一个产品，因此，他们应该有着相同的 Product Goal、Product Backlog 和 Product Owner。

Scrum Team 负责所有与产品相关的活动，像是与利害关系人（stakeholder）的协同合作、验证、维护、营运、实验、研究、和开发以及任何其他可能需要的工作。组织成立 Scrum Team 并授权他们自行管理工作。在 Sprint 中维持可持续的步调工作，可以加强 Scrum Team 的专注与一致性。

整个 Scrum Team 都有责任在每个 Sprint 中创造出有价值的、有用的 Increment。 Scrum 在 Scrum Team 中定义了三种特定的当责（accountabilities）：Developers、Product Owner 和 Scrum Master。

Developers⌗

Scrum Team 当中的 Developers 是指在每个 Sprint 致力于打造任何可用 Increment 的成员。

Developers 所须具备的特定技能通常很广泛，并且会随着工作领域不同而有别。然而，Developers 总是对以下事项负有责任：

  1. 打造一份 Sprint 的计划，也就是 Sprint Backlog；
  2. 藉由遵循完成之定义，以灌输品质；
  3. 每天调适其迈向 Sprint Goal 的计划；和，
  4. 作为专业人士对彼此负责。

Product Owner⌗

Product Owner 负责将把 Scrum Team 的工作所打造出来的产品价值最大化。如何做到这一点可能会依组织、Scrum Teams 和个人的不同而有极大的差异。

Product Owner 也负责对 Product Backlog 进行有效的管理，包括：

  1. 开发并明确的描述沟通 Product Goal；
  2. 创造并清楚的描述沟通 Product Backlog items；
  3. 对 Product Backlog items 进行排序；和，
  4. 确保 Product Backlog 是透明的、可见的与可理解的。

Product Owner 可以自己做上述工作，或者也可以将职责委托他人，然而，Product Owner 仍肩负最终责任。 为了让 Product Owners 成功，整个组织必须尊重他们的决定，这些决定在 Product Backlog 内容和顺序中可以被看见，并且在 Sprint Review 时透过可检视的 Increment 展现出来。 Product Owner 是一个人，而不是一个委员会。在 Product Backlog 中， Product Owner 可能代表了许多利害关系人（stakeholders）的需求，想要改变 Product Backlog 的人可以试着去说服 Product Owner。

Scrum Master⌗

Scrum Master 负责按照 Scrum 指南来建立 Scrum，方式是透过帮助 Scrum Team 内与组织内部的每个人了解 Scrum 的理论与实作。

Scrum Master 对 Scrum Team 的效能负责。他们透过让 Scrum Team 在 Scrum 框架内改善其实务作法来做到这一点。

Scrum Masters 是真正的领导者，服务对象是 Scrum Team 和更大范围的组织。

Scrum Master 以多种方式服务 Scrum Team ，其中包括：

  1. 以教练方式提升团队成员的自我管理（self-management）与跨职能能力（cross-functionality）；
  2. 协助 Scrum Team 专注于打造出满足完成之定义且具备高价值的 Increments；
  3. 促使 Scrum Team 的阻碍被移除掉；
  4. 确保所有的 Scrum 事件都举行，有建设性、有成效的并且保持在时间盒（timebox）内进行。

Scrum Master 以多种方式服务 Product Owner，其中包括：

  1. 帮助找到有效定义 Product Goal 与管理 Product backlog 的技巧；
  2. 帮助 Scrum Team 理解为何需要清楚且简明的 Product Backlog items；
  3. 帮助在错综复杂（complex）的环境下，建立以经验为导向的产品计划；和，
  4. 当被要求或需要时，引导利害关系人（stakeholder）的协同运作。

Scrum Master 以多种方式服务组织，其中包括：

  1. 在组织采用 Scrum 的过程中，以领导、训练和教练方式带领组织；
  2. 在组织内，规划并指导 Scrum 的执行运作；
  3. 帮助员工和利害关系人（stakeholders）理解与制定以经验为导向的方法来处理错综复杂（complex）的工作；
  4. 移除利害关系人（stakeholders）与 Scrum Teams 之间的障碍。

Scrum 事件⌗

Sprint 是所有其他事件的容器。 Scrum 中的每个事件都是用来检视与调适 Scrum artifacts 的正式机会。这些事件都是为实现所需要的透明性而特别设计的。未能按规定运作任何事件将导致失去检视和调适的机会。 Scrum 使用事件来创造规律性，并以此减少 Scrum 中未定义的会议的需要。最理想的是，所有事件都在同一时间同一地点举行，以减少复杂性。

The Sprint⌗

Sprint 是 Scrum 的核心，在这里能将创意转化为价值。

Sprint 是固定时间长度的事件，为期一个月或更短，以保持一致性。前一个 Sprint 结束，下个新 Sprint 就紧接着开始。

所有为了达成 Product Goal 的工作都发生在各个 Sprints 内，包括 Sprint Planning、Daily Scrums、Sprint Review、和 Sprint Retrospective。

在 Sprint 期间：

  1. 不得做出危及 Sprint Goal 的改变；
  2. 不得降低品质；
  3. 需要时将 Product Backlog 精炼；
  4. 随着学到更多，可以与 Product Owner 针对范畴作进一步澄清与重新协商。

藉由至少每个月一次对迈向 Product Goal 的进度来进行检视与调适，Sprint 促成了可预测性。当 Sprint 的时间太长，可能导致 Sprint Goal 失效，复杂性的程度可能会上升，以及风险可能会增高。采用时间较短的 Sprint，可以建立更多学习周期，并将成本与气力的风险控制在一个较短的时间内。每一个 Sprint 都可以视为一个短期专案。

用来预测进度的实务做法有很多种，像是燃尽图、燃起图，或是累积流量图。虽然这些做法是有用处的，但不能取代经验主义（empiricism）的重要性。在错综复杂（complex）的环境中，接下来会发生什么是不可知的。只有已经发生的事物才能用来做前瞻性的决策基础。

若 Sprint Goal 已经不合时宜，可以取消 Sprint。只有 Product Owner 有取消 Sprint 的权限。

Sprint Planning⌗

Sprint Planning 透过安排在 Sprint 中要执行的工作来启动 Sprint。计划是由整个 Scrum Team 协同合作所产出的。

Product Owner 确保与会者准备好讨论最重要的 Product Backlog items，以及它们如何对应到 Product Goal。 Scrum Team 也可以邀请其他人参与 Sprint Planning 以提供建议。

Sprint Planning 处理以下主题：

主题一：为什么这次 Sprint 有价值？⌗

Product Owner 提议产品如何在这次的 Sprint 中增加其价值和实用性。然后整个 Scrum Team 协同合作定义出 Sprint Goal，并与利害关系人（stakeholders）沟通为什么这个 Sprint 是有价值的。Sprint Goal 必须在 Sprint Planning 结束前被确定下来。

主题二：这次 Sprint 能完成（Done）什么？⌗

透过与 Product Owner 的讨论，Developers 从 Product Backlog 内选择一些项目，并放入目前的 Sprint 中。 Scrum Team 可以在这个过程中精炼这些项目，从而增加理解与信心。

选择在 Sprint 中可以完成多少项目可能会有挑战，但是，Developers 越知道他们以往的表现、他们接下来的产能、与他们对完成之定义了解得越多，他们对 Sprint 的预测就越有信心。

主题三：如何完成所挑选的工作？⌗

对于每个选定的 Product Backlog item，Developers 会计划必要的工作，以便创造符合完成之定义的 Increment。这个过程通常会把 Product Backlog items 拆解成等于或小于一天的较小工作。但要如何拆解是完全由 Developers 来决定。没有人告诉他们要如何把 Product Backlog items 转化成具有价值的 Increments。

所谓的 Sprint Backlog 是由 Sprint Goal、该 Sprint 所选的 Product Backlog items，以及如何交付的计划所组成。

Sprint Planning 是有时间盒限定（timeboxed）的，一个月的 Sprint 最多为八个小时；而较短的 Sprint，这个事件所需时间通常会更短。

Daily Scrum⌗

Daily Scrum 的用途是检视目前 Sprint Goal 的进度，并根据需要调适 Sprint Backlog，以调整即将到来的计划工作。

Daily Scrum 是一个属于 Scrum Team 当中的 Developers 的 15 分钟事件。为了降低复杂性，它在 Sprint 内的每个工作天会在同样时间、同样地点举行。如果 Product Owner 或 Scrum Master 积极地打造 Sprint Backlog 上的工作项目，他们会以 Developers 的身份参与。

Developers 可以选择他们想要的任何 Daily Scrum 的结构和技术，只要他们的 Daily Scrum 专注于实现 Sprint Goal 的进展，并且产生下一个工作天可执行的计划。这样可以更专注并改进自我管理（self-management）。

Daily Scrum 增加沟通、点出障碍、促进快速决策，从而消除其他会议的需要。

Daily Scrum 并不是 Developers 唯一一次允许调整计划的时间，在一整天的工作中，他们常常会见面详细讨论要如何做出调适，或是重新计划 Sprint 剩下的工作。

Sprint Review⌗

Sprint Review 的用途是检视此 Sprint 的成果和决定未来的调适方向。 Scrum Team 向利害关系人（stakeholders）展示他们的工作结果，并讨论 Product Goal 的进展情况。

在这个事件中，Scrum Team 与利害关系人（stakeholders）回顾在 Sprint 中完成的成果，以及环境发生了什么变化，基于这些资讯，与会者对接下来要做什么进行协同合作，也可调整 Product Backlog，借此来掌握新的机会。 Sprint Review 是一个工作会议，Scrum Team 应避免将其限于投影片展示。

Sprint Review 是每个 Sprint 最后倒数的第二个事件，是有时间盒限定（timeboxed）的：一个月的 Sprint 最多为四个小时；而较短的 Sprint，这个事件所需时间通常会更短。

Sprint Retrospective⌗

Sprint Retrospective 的用途是规划出能提升品质与效能的方法。

Scrum Team 检视上个 Sprint 中有关人员、互动、流程、工具以及他们的完成之定义的情况。被检视的元素通常随工作领域而不同。团队会辨识出他们迷失方向的假设，并探究这些假设的起源。

Scrum Team 讨论此次 Sprint 中，什么进展顺利，遇到哪些问题，以及如何（或为何无法）解决这些问题。

Scrum Team 辨识出最有用的改变以提升其效能。最具冲击力的改善行动将尽速执行。甚至可以纳入到下一个 Sprint 的 Sprint Backlog 中。

Sprint Retrospective 是总结 Sprint 的事件。是有时间盒限定（timeboxed）的，以一个月的 Sprint 来说，最多为 3 个小时；而较短的 Sprint，这个事件所需时间通常会更短。

Scrum Artifacts⌗

Scrum 的 artifacts 所代表的是工作或价值。 Artifacts 的设计是为了使关键资讯之透明性极大化。因此，每个检视这些 artifacts 的人，对于调适，都会有相同的基础。每个 artifact 都包含一个承诺，以确保它提供可增强透明性和专注度，给以下可以进度量测的事物：

  1. 对于 Product Backlog 而言，它是 Product Goal；
  2. 对于 Sprint Backlog 而言，它是 Sprint Goal；
  3. 对于 Increment 而言，它是完成之定义。 这些承诺的存在是为了强化经验主义（empiricism）和 Scrum Team 及其利害关系人（stakeholders）的 Scrum 价值观。

Product Backlog⌗

Product Backlog 是一份涌现的（Emergent）和有顺序的清单，它列出产品需要被改善的地方，它是 Scrum Team 工作事项之唯一来源。

凡是 Scrum Team 能够在一个 Sprint 中完成（Done）的 Product Backlog items ，就可视为是备妥的，而可在 Sprint Planning 中被挑选。通常在精炼活动后才可达到这样的透明性。 Product Backlog 的精炼是将 Product Backlog items 拆解并进一步定义，使其变得更小、更精确的活动。这是一项持续进行的活动，加入更多描述、顺序与大小之类的细节。这些属性通常随工作领域而不同。

实际从事工作的 Developers 要负责其适当的大小。 Product Owner 可以藉由帮助 Developers 理解和权衡取舍来影响他们。

Product Goal⌗

Product Goal 描述了产品的未来状态，可以作为 Scrum Team 制定计划的目标。 Product Goal 在 Product Backlog 中。 Product Backlog 的其余部分会涌现出来以定义「做哪些事情」可以实现 Product Goal。

产品是交付价值的载具，它具有明确的边界、已知的利害关系人（stakeholders）、定义明确的使用者或客户。产品可以是一种服务、一个实体的产品，或是更抽象的东西。Product Goal 是 Scrum Team 的长期目标，他们必须完成（或放弃）一个目标才能再开始下一个。

Sprint Backlog⌗

Sprint Backlog 是由 Sprint Goal（为什么做）、该 Sprint 所选择的 Product Backlog items（做些什么）以及用来交付 Increment 的执行计划（如何做到）。

Sprint Backlog 是 Developers 所制定并专属的计划。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而规划要完成的工作，是一个工作高度可视且即时的工作画面。因此，随着学到更多，Sprint Backlog 会在整个 Sprint 期间进行更新。它应该有足够的细节，以便可以在 Daily Scrum 中检视其进度。

Sprint Goal⌗

Sprint Goal 是 Sprint 的单一目标，尽管 Sprint Goal 是由 Developers 所做出的承诺，但它为实现该目标所需的确切工作提供了弹性。 Sprint Goal 还创造了连贯性和专注性，鼓励 Scrum Team 一起工作而不是分开行事。

Sprint Goal 是在 Sprint Planning 事件中被创造出来，然后添加到 Sprint Backlog 里。当 Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作跟他们原本预期的不一样，他们会与 Product Owner 协同合作，在不影响 Sprint Goal 的情况下，来协商 Sprint Backlog 的范围。

Increment⌗

一个 Increment 是迈向 Product Goal 的一块坚实踏脚石。每个 Increment 都是之前所有的 Increments 累加起来的，并经过了彻底地验证，以确保所有整合在一起的 Increment 都是可用的。为了提供价值，Increment 必须是可用的。

一个 Sprint 内可以产生多个 Increments。在 Sprint Review 时，会把所有 Increments 展示出来，从而支持经验主义（empiricism）。但是，Increment 可以在 Sprint 结束之前交付给利害关系人（stakeholders）。 Sprint Review 绝对不应该被视为发布价值的关卡。一项工作除非符合完成之定义，否则不能将其视为 Increment 的一部分。

完成之定义（DOD）⌗

完成之定义是当 Increment 符合产品所需的品质测量的正式描述。

当一个 Product Backlog item 符合完成之定义时，就会诞生一个 Increment。

完成之定义是藉由提供每个人对 Increment 中已完成工作的共同认知，而建立透明性。如果一个 Product Backlog item 不符合完成之定义 ，那么它就不能发布，甚至不能在 Sprint Review 中展示。反之，它会回到 Product Backlog 中以供将来考虑。

如果 Increment 的完成之定义是组织标准的一部分，那么所有 Scrum Teams 都必须以此为最低标准来遵守。如果它不是组织标准，那么 Scrum Team 必须制定适合该产品的完成之定义 。

Developers 需要遵循完成之定义。如果有多个 Scrum Teams 一起开发同一个产品，他们必须一起制定并遵守同样的完成之定义 。

结语⌗

Scrum 是免费的，并在本指南中提供。本文所描述的 Scrum 框架是不可改变的。虽然实施部分的 Scrum 是可能的，但结果就不是 Scrum 了。 Scrum 仅能以完整的形式存在，唯其如此也才能有效的成为其他技术、方法论和实务做法的容器。

致谢⌗

人员⌗

在为 Scrum 作出贡献的成千上万的众人当中，我们要特别指出那些在最初提供帮助的人们： Jeff Sutherland 以及与他一起工作的 Jeff McKenna 和 John Scumniotales ，还有 Ken Schwaber 以及与他一起工作的 Mike Smith 和 Chris Martin，还有他们一起工作。在随后的几年中，更多的其它人作出了贡献，如果没有他们的帮助，Scrum 将不会如同今天这般精炼。

Scrum 指南的历史⌗

Ken Schwaber 和 Jeff Sutherland 在 1995 年 OOPSLA 的大会上首次联合发表 Scrum。这场演讲本质上记录了 Ken 和 Jeff 在过去几年的学习成果，也首次公开了 Scrum 的正式定义。

Scrum 指南记录了 Jeff Sutherland 和 Ken Schwaber 在三十多年间对 Scrum 的开发，演进，和维护。其他的资源在模式、流程和见解方面为 Scrum 框架提供了补充。这些可能可以提高生产力、价值、创造力和对结果的满意度。

Scrum 的完整历史在其他地方有所记载。我们对于首先尝试并证实其有效的公司表达敬意：Individual, Inc., Newspage, Fidelity Investments, 和 IDX (现为 GE Medical)。

2020 年 Scrum 指南版本更新说明⌗

甚至更少的规定指示⌗

这些年来， Scrum 指南开始变得有一些规定指示。 2020 年版本旨在透过删除或淡化规定性用语，使 Scrum 恢复到原本最低限度的框架。例如删除了 Daily Scrum 的三个提问，淡化了关于 PBI 属性的用语，淡化了关于 Sprint Backlog 中改进项目的用语，减化了取消 Sprint 的段落，等等其它更多部分。

一个团队，专注于一个产品

目的在消除团队中有其它团队的概念，导致 PO 和 Dev 团队之间出现「代理人」或「我们跟他们」的行为。现在只有一个 Scrum 团队专注于同一目标，有三个不同当责（accountabilities）：： PO，SM 和 Developers。

加入 Product Goal⌗

2020 年 Scrum 指南引入了 Product Goal 的概念，为 Scrum Team 提供了一个更具价值的专注重点。每个 Sprint 都应使开发中的产品更接近整体的 Product Goal。

Sprint Goal、完成之定义和 Product Goal 有了归宿

先前版本的 Scrum 指南描述了 Sprint Goal 和完成之定义，但是没有真正赋予它们明确的身份。它们不全然是 artifacts，反而是类似依附在 artifacts 。随着增加了 Product Goal，2020 版本对此提供了更清晰的说明。现在，三个 artifacts 中都包含一个相对应的「承诺」。对于 Product Backlog，它相对应的是 Product Goal，Sprint Backlog 则有 Sprint Goal，而 Increment 有完成之定义（Definition of Done；现在，「完成（Done）」 英文不再加引号）。这些承诺的存在是为了带来透明性，并专注于每个 artifact 的进度。

自我管理（Self-Managing）超越自我组织（Self-Organizing）

先前版本的 Scrum 指南将 Development Team 称为自我组织的（self-organizing），他们能选择人员和如何做事。 2020 版本更加着重于 Scrum Team，强调了一个自我管理（self-managing）的 Scrum Team，他们能选择人员，如何做事，和做什么事。

三个 Sprint Planning 的主题

Sprint Planning 主题除了「什么」和「如何」之外，2020 年 Scrum 指南还强调了第三个主题 「为什么」，这里的「为什么」指的是 Sprint Goal。

扩大读者范围，全面简化用语

2020 年 Scrum 指南著重于移除冗长和错综复杂（complex）的陈述，同时也删除所有与 IT 工作相关的推断（例如，测试，系统，设计，需求等）。