Scrum 官方权威指南 收听有声版 | 官网下载PDF
由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护
版本：2020中文版 | 查看旧版本（2017）
Scrum 指南的目的 在 1990 年代初，我们开发了 Scrum。在 2010 年，我们撰写首版 Scrum 指南，以帮助全世界的人们理解 Scrum。自那时起，我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。
Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的，这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则，将掩盖问题并限制 Scrum 的好处，甚至可能变得毫无用途。
我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用，超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大，developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此，我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者，而是为了简化统称。如果您从 Scrum 中获得价值，那么您可以将自己视为其中一员。
在使用 Scrum 时，可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的，因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异，因此不在本文中描述。
Ken Schwaber & Jeff Sutherland 2020 年 11 月
Scrum指南
更少的规范性 多年以来，《Scrum指南》变得更具规范性（Prescriptive）。2020版旨在通过删除或软化说明性语言，将其恢复为最低限度的框架。
例如：
删除了每日Scrum问题， 软化了围绕PBI属性的语言， 软化了Sprint待办事项围绕回顾会的语言的条目 缩短了取消Sprint的部分等。 一个团队专注于一个产品 一个团队专注于一个产品的目的是消除团队内独立团队的概念，这会导致产品负责人（PO）和开发团队之间的“代理”或“我们和他们“的行为。现在只有一个Scrum团队专注于同一个团队目标，具有三组不同的职责：PO，SM和开发人员。
产品目标的介绍 2020版的《Scrum指南》引入了产品目标的概念，为Scrum团队向更大的有价值的目标迈进提供了重点。每个Sprint都应使产品更接近整体产品目标。
冲刺目标，完成的定义和产品目标的目录 之前的《Scrum指南》描述了Sprint目标和完成的定义，但并没有真正给它们提供身份。它们不完全是工件，而是有些附属于工件。除了2020版对产品目标提供了更清晰的说明。现在，每个工件中都包含对它们的“承诺”。
对于产品待办事项列表（Product Backlog），是产品目标； Sprint待办事项列表（Sprint Backlog）则有Sprint目标， 增量（Increment）则有完成的定义（现在不带引号）。 它们的存在是为了带来透明并专注于每个工件的进度。
自我管理超越自我组织 self-managing over self-orgainzing 之前的《Scrum指南》将开发团队称为自组织，团队选择和谁一起工作以及如何完成工作。 2020版本则更着重于Scrum团队，强调了自我管理的Scrum团队，团队选择和谁一起工作、如何做以及做什么。
三个Sprint计划的主题 除了“什么”和“如何”的Sprint计划主题外，2020的《Scrum指南》还强调了第三个主题“为什么”，指的是冲刺目标（Sprint Goal）。
全面简化语言，扩大受众范围 2020版本的《Scrum指南》着重于消除冗余和复杂的陈述，以及消除了余下的对IT工作的任何推断（例如测试，系统，设计，需求等）。现在，《 Scrum指南》不到13页。
加入社区？ 加入社区参与讨论？
欢迎报名我的线上课程 - Scrum敏捷精髓
敏捷快速入门指南 《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。
Scrum主题
产品列表梳理会议快速入门指南 每日站会快速入门指南 Sprint规划快速入门指南 Sprint评审快速入门指南 Sprint回顾快速入门指南 其他主题：
故事拆分快速入门指南 编写清晰明确的用户故事快速入门指南 Product Backlog Refinement 简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。
定义 产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面：
由产品经理和产品负责人领导的，需求功能不断定义、完善、澄清以及重新确定顺序； 在Sprint开始之前进行的一次协作会议，以评估新信息，确保准备开发下一组故事。 频率 每个Sprint一次（通常是Sprint中，下一个Sprint开始前的1-5天不等） 注意：某些团队选择每个Sprint进行多次”梳理”会话。如2周的SPrint，可能一周梳理1次。
持续时间 团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。）
参与者、输入、输出 参与者 – 产品负责人，ScrumMaster，开发团队 输入 – 主要输入是为即将到来的Sprint预测的用户故事，这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此，如果团队确定依赖性，并有了影响多个故事的优先级或工作量的新信息，那么就可以灵活处理。 输出 – 整个团队达成共识，就一组排好序、清晰定义且独立的用户故事达成共识。 活动 产品列表梳理期间的活动通常包括：
查看从当前Sprint中学到的新信息 讨论最快速度、可能速度和最差速度 是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作？ 在回答这个问题时，请牢记可持续的步伐 对于团队来说，在Sprint中去现实地评估事情，比等到Sprint结束后再进行任何变更，要好的多（香不香？）。 查看并澄清即将发布的用户故事 讨论并同意验收标准（Acceptance Criteria），以确认双方的理解。以及确认估算大小和拆分太大的故事 提醒：任何故事，如果团队在一个SPrint内无法完成4个，那么就是太大了。 同意下一个Sprint的计划 根据我们的速度预测和大小确定，这是一个现实的计划吗？ 如果对上一个问题的回答为”否”，则拆分故事，或交换优先级相近的小故事，直到团队对计划充满信心为止 注意：另请参阅多年前我写的产品列表梳理
Scrum 官方权威指南 收听有声版 | 官网下载PDF
由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护
版本：2017中文版
Scrum 指南的目的 Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本 Scrum 指南 包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。
Scrum 的定义 Scrum（名词）： Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。
Scrum 是：
轻量级的 易于理解的 难以精通的 Scrum 是一个框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。
Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。
Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。
使用 Scrum 框架的其它不同特定技巧将不在本文中描述。
Scrum 的应用 Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范围内已得到了广泛应用：
