2020 Scrum 指南™
Scrum 指南的目的
我们在 20 世纪 90 年代初开发了 Scrum。为了帮助世界各地的人们理解 Scrum，我们于 2010 年编写了第一版《Scrum 指南》。此后，我们通过一些小的功能性更新不断完善该指南。我们共同支持并维护这份指南。
《Scrum 指南》包含了 Scrum 的定义。框架中的每个元素都服务于特定的目的，这些目的对于 Scrum 实现整体价值和成果至关重要。改变 Scrum 的核心设计或理念、省略某些元素或不遵守 Scrum 的规则，都会掩盖问题并限制 Scrum 的优势，甚至可能使其失效。
我们密切关注着 Scrum 在日益复杂的世界中的广泛应用。我们欣喜地看到，Scrum 的应用已扩展到许多其他领域，这些领域本身就包含着复杂的工作，而不仅仅局限于 Scrum 的发源地——软件产品开发。随着 Scrum 应用的普及，开发人员、研究人员、分析师、科学家和其他专业人士都在参与其中。我们在 Scrum 中使用“开发人员”一词并非为了排除任何人，而是为了简化说明。如果您能从 Scrum 中获益，那么请将自己也纳入其中。
在 Scrum 的实际应用中，可以发现、应用和设计符合本文档所述 Scrum 框架的模式、流程和见解。由于这些模式、流程和见解具有情境敏感性，并且在不同的 Scrum 应用场景中差异很大，因此对其进行详细描述超出了 Scrum 指南的范围。在 Scrum 框架内使用这些策略的方法多种多样，相关内容已在其他文献中有所描述。
Scrum 定义
Scrum 是一种轻量级框架，它通过针对复杂问题的自适应解决方案来帮助个人、团队和组织创造价值。
简而言之，Scrum 需要 Scrum Master 来营造一种这样的环境：
- 产品负责人将复杂问题的解决方案整理到产品待办事项列表中。
- Scrum 团队在 Sprint 期间将一部分工作转化为一个价值增量。
- Scrum 团队及其利益相关者会检查结果，并为下一个 Sprint 进行调整。
- 重复
Scrum 很简单。您可以直接尝试，看看它的理念、理论和结构是否能帮助您实现目标并创造价值。Scrum 框架有意设计得并不完整，仅定义了实施 Scrum 理论所需的部分。Scrum 的构建依赖于使用者的集体智慧。Scrum 的规则并非提供详细的操作指南，而是引导使用者之间的关系和互动。
Scrum框架内可以采用各种流程、技术和方法。它可以对现有实践进行整合，或者使其变得不再必要。Scrum能够清晰地展现当前管理、环境和工作技术的相对有效性，从而实现改进。
Scrum理论
Scrum 建立在经验主义和精益思维之上。经验主义认为知识来源于经验，决策应基于观察所得。精益思维则致力于减少浪费，专注于本质要素。
Scrum 采用迭代式、增量式的方法来优化可预测性并控制风险。Scrum 让团队成员共同协作，这些成员具备完成工作所需的所有技能和专业知识，并根据需要共享或获取这些技能。
Scrum 将四个正式的检查和调整活动整合到一个包含性活动——Sprint 中。这些活动之所以有效，是因为它们实现了 Scrum 的经验支柱：透明性、检查和调整。
透明度
对于执行者和接收者而言，涌现的过程和工作必须清晰可见。在 Scrum 中，重要决策基于对三个正式工件状态的感知。低透明度的工件可能导致降低价值并增加风险的决策。
透明度使审查成为可能。缺乏透明度的审查会产生误导，造成浪费。
检查
必须经常且认真地检查 Scrum 工件和目标达成进度，以便发现潜在的不良偏差或问题。为了帮助进行检查，Scrum 通过其五个事件来提供节奏。
检查促成调整。没有调整的检查毫无意义。Scrum 活动旨在促成改变。
适应
如果工艺流程的任何方面超出可接受的范围，或者最终产品不合格，则必须调整所采用的工艺流程或所生产的材料。必须尽快进行调整，以最大程度地减少进一步的偏差。
当相关人员缺乏授权或自我管理能力时，适应就会变得更加困难。Scrum 团队需要通过观察学习到任何新知识后立即做出调整。
Scrum价值观
Scrum 的成功运用取决于人们能否更熟练地践行以下五项价值观：
承诺、专注、开放、尊重和勇气
Scrum 团队致力于实现目标并互相支持。他们的首要任务是专注于 Sprint 工作，力求在实现这些目标的过程中取得最佳进展。Scrum 团队及其利益相关者对工作和挑战保持开放的态度。Scrum 团队成员彼此尊重，视对方为有能力、独立自主的人，并因此受到与他们共事的人的尊重。Scrum 团队成员勇于做正确的事，并致力于解决棘手的问题。
这些价值观为 Scrum 团队的工作、行动和行为指明了方向。所做的决策、采取的步骤以及 Scrum 的使用方式都应该强化这些价值观，而不是削弱或破坏它们。Scrum 团队成员在参与 Scrum 活动和使用 Scrum 工件的过程中学习和探索这些价值观。当 Scrum 团队及其合作者践行这些价值观时，透明、检查和适应这三大 Scrum 支柱便得以实现，从而建立信任。
Scrum 团队
Scrum 的基本单元是小型团队，即 Scrum 团队。Scrum 团队由一名 Scrum Master、一名产品负责人和几名开发人员组成。Scrum 团队内部没有子团队或层级结构。它是一个紧密协作的专业团队，专注于一次只完成一个目标，即产品目标。
Scrum团队是跨职能的，这意味着团队成员具备在每个迭代周期（Sprint）创造价值所需的所有技能。他们也是自我管理的，这意味着他们内部会决定谁做什么、何时做以及如何做。
Scrum 团队规模适中，既能保持灵活，又能在一个迭代周期内完成重要的工作，通常由 10 人或更少的人组成。我们发现，规模较小的团队沟通更顺畅，效率更高。如果 Scrum 团队规模过大，则应考虑重组为多个紧密协作的 Scrum 团队，每个团队专注于同一个产品。因此，这些团队应该共享相同的产品目标、产品待办事项列表和产品负责人。
Scrum 团队负责所有与产品相关的活动，包括与利益相关者协作、验证、维护、运营、实验、研发以及其他任何可能需要的事项。组织赋予 Scrum 团队组织架构和自主权，使其能够管理自身的工作。以可持续的节奏进行迭代开发 (Sprint) 有助于提升 Scrum 团队的专注度和工作一致性。
整个 Scrum 团队都有责任在每个 Sprint 中创建一个有价值、有用的增量。Scrum 定义了 Scrum 团队内部的三个具体职责：开发人员、产品负责人和 Scrum Master。
开发者
开发人员是 Scrum 团队中负责在每个 Sprint 中创建可用增量各个方面的人员。
开发人员所需的具体技能通常很广泛，并且会因工作领域而异。但是，开发人员始终对以下方面负责：
- 制定冲刺计划和冲刺待办事项列表；
- 通过坚持“完成定义”来灌输质量标准；
- 他们每天都会根据冲刺目标调整计划；并且，
- 作为专业人士，要互相监督，确保彼此承担责任。
产品负责人
产品负责人负责最大化 Scrum 团队工作成果的产品价值。具体实现方式可能因组织、Scrum 团队和个人而异。
产品负责人还负责有效的产品待办事项管理，其中包括：
- 制定并明确传达产品目标；
- 创建并清晰地传达产品待办事项；
- 对产品待办事项进行排序；以及，
- 确保产品待办事项列表透明、可见且易于理解。
产品负责人可以亲自完成上述工作，也可以将职责委托给其他人。无论如何，产品负责人始终要承担责任。
产品负责人要想取得成功，整个组织都必须尊重他们的决策。这些决策体现在产品待办事项列表的内容和顺序中，也体现在迭代评审会议上可检查的增量中。
产品负责人是一个人，而不是一个委员会。产品负责人可以代表产品待办事项列表中众多利益相关者的需求。想要修改产品待办事项列表的人可以通过尝试说服产品负责人来实现。
Scrum Master
Scrum Master 负责按照 Scrum 指南中的定义建立 Scrum 流程。他们通过帮助 Scrum 团队和组织内的所有人理解 Scrum 的理论和实践来实现这一目标。
Scrum Master 对 Scrum 团队的效率负责。他们通过帮助 Scrum 团队在 Scrum 框架内改进其实践来实现这一目标。
Scrum Master 是真正的领导者，他们服务于 Scrum 团队和整个组织。
Scrum Master 通过多种方式为 Scrum 团队提供服务，包括：
- 指导团队成员进行自我管理和跨部门协作；
- 帮助 Scrum 团队专注于创建符合完成定义的高价值增量；
- 消除 Scrum 团队进展中的障碍；以及，
- 确保所有 Scrum 活动都能顺利进行，并且是积极、高效的，同时保持在规定的时间内完成。
Scrum Master 通过多种方式为产品负责人提供服务，包括：
- 帮助寻找有效的产品目标定义和产品待办事项管理方法；
- 帮助 Scrum 团队理解清晰简洁的产品待办事项列表的必要性；
- 帮助建立针对复杂环境的实证产品规划；以及，
- 根据要求或需要，促进利益相关者的合作。
Scrum Master 通过多种方式为组织服务，包括：
- 领导、培训和指导组织采用 Scrum 方法；
- 规划和指导组织内部的 Scrum 实施；
- 帮助员工和利益相关者理解并运用实证方法处理复杂工作；以及，
- 消除利益相关者与 Scrum 团队之间的障碍。
Scrum 活动
Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检查和调整 Scrum 工件的正式机会。这些事件经过精心设计，旨在实现所需的透明度。任何事件若未按规定执行，都将导致错失检查和调整的机会。Scrum 使用事件来建立规律性，并最大限度地减少 Scrum 中未定义的会议。
理想情况下，所有活动都应在同一时间、同一地点举行，以降低复杂性。
冲刺
迭代是 Scrum 的核心，它能将想法转化为价值。
为了保持一致性，这些迭代周期固定为一个月或更短。新的迭代周期在前一个迭代周期结束后立即开始。
为实现产品目标所需的所有工作，包括 Sprint 计划会议、每日站会、Sprint 评审会议和 Sprint 回顾会议，都在 Sprint 周期内完成。
冲刺期间：
- 不会做出任何危及冲刺目标的改变；
- 质量不会下降；
- 产品待办事项列表会根据需要进行完善；并且，
- 随着了解更多信息，范围可以与产品负责人进行澄清和重新协商。
迭代周期通过确保至少每月一次对产品目标进度进行检查和调整，从而实现可预测性。如果迭代周期过长，迭代目标可能会失效，复杂性可能会增加，风险也可能上升。缩短迭代周期可以产生更多的学习周期，并将成本和工作量风险控制在较短的时间范围内。每个迭代周期都可以被视为一个短期项目。
预测进展的方法有很多，例如燃尽图、燃尽图或累积流量图。虽然这些方法已被证明有效，但它们并不能取代经验的重要性。在复杂的环境中，未来会发生什么是未知的。只有已经发生的事情才能用于前瞻性决策。
如果冲刺目标过时，则可以取消冲刺。只有产品负责人有权取消冲刺。
冲刺计划
迭代计划会议通过规划迭代周期内要完成的工作来启动迭代。最终的计划是由整个 Scrum 团队协作制定的。
产品负责人确保与会者做好准备，讨论最重要的产品待办事项以及它们如何与产品目标相对应。Scrum 团队也可能邀请其他人参加 Sprint 计划会议，提供建议。
迭代计划会议涵盖以下主题：
主题一：本次冲刺的价值何在？
产品负责人提出如何在当前迭代周期内提升产品的价值和实用性。随后，整个 Scrum 团队协作制定迭代目标，阐明本次迭代对利益相关者的价值所在。迭代目标必须在迭代计划会议结束前最终确定。
主题二：本次迭代可以完成哪些工作？
开发人员通过与产品负责人讨论，从产品待办事项列表中选择要纳入当前迭代的条目。Scrum 团队可能会在此过程中对这些条目进行完善，从而加深理解并增强信心。
选择在迭代周期内能够完成的工作量可能颇具挑战性。然而，开发人员越了解他们过去的表现、未来的工作能力以及完成标准，他们就越能自信地预测迭代周期的完成情况。
主题三：如何完成所选工作？
对于每个选定的产品待办事项，开发人员会规划创建符合“完成定义”的增量所需的工作。这通常是通过将产品待办事项分解成一天或更短时间内即可完成的较小工作项来实现的。具体如何分解完全由开发人员自行决定。没有人可以告诉他们如何将产品待办事项转化为有价值的增量。
冲刺目标、为冲刺选择的产品待办事项以及交付这些待办事项的计划，统称为冲刺待办事项列表。
对于为期一个月的迭代周期，迭代计划会议的时间限制为最多八小时。对于较短的迭代周期，会议时间通常也会相应缩短。
每日站会
每日站会的目的是检查冲刺目标的进展情况，并根据需要调整冲刺待办事项列表，调整即将进行的计划工作。
每日站会是 Scrum 团队开发人员的 15 分钟会议。为了简化流程，它在每个 Sprint 工作日的同一时间和地点举行。如果产品负责人或 Scrum Master 正在积极处理 Sprint 待办事项列表中的条目，他们也会以开发人员的身份参加。
开发人员可以自由选择任何他们喜欢的结构和技术，只要他们的每日站会能够聚焦于冲刺目标的进展情况，并为第二天的工作制定出可行的计划即可。这有助于集中精力，并提高自我管理能力。
每日站会可以改善沟通，发现障碍，促进快速决策，从而消除召开其他会议的必要性。
每日站会并不是开发人员调整计划的唯一时机。他们通常会在一天中多次开会，进行更详细的讨论，以调整或重新计划冲刺剩余的工作。
冲刺回顾
Sprint评审的目的是检查Sprint的成果并确定未来的调整方向。Scrum团队会向关键利益相关者展示他们的工作成果，并讨论产品目标的进展情况。
在本次活动中，Scrum 团队和利益相关者会回顾 Sprint 中已完成的工作以及环境的变化。基于这些信息，与会者会协作制定下一步计划。产品待办事项列表也可能会进行调整，以抓住新的机遇。Sprint 评审会议是一个工作会议，Scrum 团队应避免将其局限于演示环节。
冲刺评审是冲刺周期的倒数第二个活动，对于一个月的冲刺周期，其时间限制为最多四个小时。对于较短的冲刺周期，该活动的时间通常也会相应缩短。
冲刺回顾
Sprint回顾会议的目的是规划提高质量和效率的方法。
Scrum 团队会检查上一个 Sprint 的执行情况，包括人员、交互、流程、工具以及完成定义 (Definition of Done)。检查的内容通常会因工作领域而异。团队会找出导致偏差的假设，并探究其根源。Scrum 团队还会讨论 Sprint 期间哪些方面做得好，遇到了哪些问题，以及这些问题是如何解决（或未能解决）的。
Scrum团队会找出最有助于提升效率的改进措施。最具影响力的改进措施会尽快落实，甚至可能被添加到下一个Sprint的待办事项列表中。
冲刺回顾会议标志着冲刺的结束。对于为期一个月的冲刺，会议时间最多为三小时。对于较短的冲刺，会议时间通常也会相应缩短。
Scrum工件
Scrum 的工件代表工作或价值。它们的设计旨在最大限度地提高关键信息的透明度。因此，所有查看这些工件的人都拥有相同的调整基础。
每项成果都包含一项承诺，即确保其提供的信息能够提高透明度，并集中精力，以便衡量进展：
- 对于产品待办事项列表而言，它就是产品目标。
- 对于冲刺待办事项列表来说，它就是冲刺目标。
- 对于增量操作而言，这就是完成的定义。
这些承诺旨在加强 Scrum 团队及其利益相关者的经验主义和 Scrum 价值观。
产品待办事项列表
产品待办事项列表是一个不断更新、有序的清单，列出了改进产品所需的各项工作。它是 Scrum 团队开展工作的唯一来源。
能够在一次迭代周期内由 Scrum 团队完成的产品待办事项，即可在迭代计划会议上进行选择。这些待办事项通常在经过细化活动后才能达到这种透明度。产品待办事项细化是指将产品待办事项分解并进一步定义成更小、更精确的条目。这是一项持续进行的活动，旨在添加诸如描述、顺序和大小等详细信息。属性通常会因工作领域而异。
负责具体工作的开发人员负责项目规模的确定。产品负责人可以通过帮助开发人员理解和选择权衡方案来影响他们的决策。
承诺：产品目标
产品目标描述了产品的未来状态，可作为 Scrum 团队制定计划的参考依据。产品目标位于产品待办事项列表中。产品待办事项列表中的其余部分则用于定义实现产品目标所需的“内容”。
产品是传递价值的载体。它具有清晰的边界、明确的利益相关者和明确的用户或客户。产品可以是服务、有形产品，也可以是更抽象的概念。
产品目标是 Scrum 团队的长期目标。他们必须先完成（或放弃）一个目标，才能着手下一个目标。
冲刺待办事项
Sprint Backlog 由 Sprint 目标（为什么）、为 Sprint 选择的产品待办事项集（什么）以及交付增量的可操作计划（如何）组成。
Sprint Backlog 是由开发人员制定并供开发人员使用的计划。它清晰地实时展示了开发人员在 Sprint 期间为实现 Sprint 目标而计划完成的工作。因此，随着 Sprint 期间了解更多信息，Sprint Backlog 会不断更新。它应该包含足够的细节，以便开发人员在每日站会上查看进度。
承诺：冲刺目标
冲刺目标是本次冲刺的唯一目标。虽然冲刺目标是开发人员的承诺，但它在实现目标的具体工作内容方面留有灵活性。冲刺目标还能增强团队的凝聚力和专注力，鼓励 Scrum 团队协同工作，而不是各自为政。
冲刺目标在冲刺计划会议期间制定，然后添加到冲刺待办事项列表中。开发人员在冲刺期间工作时，会始终牢记冲刺目标。如果工作内容与预期不符，他们会与产品负责人协作，在不影响冲刺目标的前提下，在冲刺期间调整冲刺待办事项列表的范围。
增量
增量是实现产品目标的具体步骤。每个增量都建立在所有先前增量的基础上，并经过全面验证，确保所有增量协同工作。为了创造价值，增量必须易于使用。
在一个迭代周期内可以创建多个增量。迭代评审会议上会展示所有增量的总和，从而支持经验主义。但是，增量可以在迭代周期结束前交付给利益相关者。迭代评审会议绝不应被视为发布价值的门槛。
只有符合“完成定义”的工作才能被视为增量的一部分。
承诺：完成的定义
完成的定义是对增量状态的正式描述，即当增量满足产品所需的质量指标时的状态。
当产品待办事项符合完成的定义时，一个增量就诞生了。
完成定义通过让所有人对增量中已完成的工作达成共识，从而提高透明度。如果产品待办事项不符合完成定义，则不能发布，甚至不能在迭代评审会议上展示。相反，它将返回产品待办事项列表，以供将来考虑。
如果增量完成定义是组织标准的一部分，则所有 Scrum 团队至少必须遵循该定义。如果它不是组织标准，则 Scrum 团队必须为产品创建合适的完成定义。
开发人员必须遵守完成定义。如果多个 Scrum 团队共同开发一个产品，他们必须共同定义并遵守同一份完成定义。
尾注
Scrum 是免费的，并在本指南中提供。本文概述的 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 的完整历史已在其他地方有所描述。为了纪念 Scrum 最早的试验和验证案例，我们在此表彰 Individual Inc.、Newspage、Fidelity Investments 和 IDX（现为 GE Medical）。