共计 3581 个字符，预计需要花费 9 分钟才能阅读完成。
今天（2017 年 11 月 7 日），Ken Schwaber 和 Jeff Sutherland 发布了 Scrum 指南的更新。Scrum 指南是 Scrum 的最终定义，由 Scrum 的创建者 Ken 和 Jeff 编写。《Scrum 指南》描述了 Scrum 框架。而且，它只有 19 页长。通过保持简短的定义，它不仅强制实现一个明确的重点，而且提醒每个人它不是一种方法论。过程是根据团队所处的情况使用框架而产生的。因为 Scrum 关注复杂的问题，所以不可能定义完整的方法论。相反，Scrum 提供了一个简单的框架，鼓励正确的经验过程出现。这使得现在超过 1200 万人可以练习 Scrum，同时在非常不同的情况下解决非常不同的问题。
添加了有关 Scrum 使用的部分：
Scrum 最初是为管理和开发产品而开发的。从 20 世纪 90 年代初开始，Scrum 在全球广泛使用：
研究和确定可行的市场，技术和产品能力;
开发产品和改进;
每天多次发布产品和增强功能;
开发和维护云（在线，安全，按需）和其他操作环境以供产品使用; 和，
维持和更新产品。
Scrum 已被用于开发软件，硬件，嵌入式软件，交互功能网络，自动驾驶汽车，学校，政府，市场营销，管理组织的运作以及我们日常生活中使用的几乎所有东西，如个人和社会。
随着技术，市场和环境的复杂性及其相互作用的迅速增加，Scrum 在处理复杂性方面的实用性每天都在证明。事实证明，Scrum 在迭代和增量知识转移方面特别有效。Scrum 现在广泛用于产品，服务和上级组织的管理。Scrum 的本质是一个小团队。个人团队非常灵活和适应性强。这些优势继续在单个，多个，多个团队网络中运行，这些团队开发，发布，运营和维护数千人的工作和工作产品。他们通过复杂的开发架构和目标发布环境进行协作和互操作。
当 Scrum 指南中使用“develop”和“development”这两个词时，它们指的是复杂的工作，例如上面提到的那些类型。
更改了“Scrum Master”部分中的措辞，以更好地阐明角色。现在的案文如下：Scrum Master 负责推广和支持 Scrum 指南中定义的 Scrum。Scrum Masters 通过帮助每个人理解 Scrum 理论，实践，规则和价值观来实现这一目标。
Scrum Master 是 Scrum 团队的仆人领导者。Scrum Master 帮助 Scrum 团队以外的人了解他们与 Scrum 团队的哪些互动是有用的，哪些不是。Scrum Master 帮助每个人改变这些交互，以最大化 Scrum 团队创造的价值。
添加到产品负责人的 Scrum Master Service 部分 确保 Scrum 团队中的每个人都能够理解目标，范围和产品领域。
将 Daily Scrum 部分的第一段更新为：Daily Scrum 是一个 15 分钟的开发团队时间盒活动。每日 Scrum 每天都在 Sprint 举行。在此，开发团队计划在接下来的 24 小时内开展工作。通过检查自上次每日 Scrum 以来的工作并预测即将到来的 Sprint 工作，这可以优化团队协作和性能。Daily Scrum 每天都在同一时间和地点举行，以降低复杂性。
更新了每日 Scrum 部分，以明确 Daily Scrum 的目标，包括以下文本：
会议结构由开发团队制定，如果侧重于 Sprint 目标的进展，可以采用不同的方式进行。一些开发团队将使用问题，一些将更多基于讨论。以下是可能使用的示例：
昨天我做了什么帮助开发团队实现 Sprint 目标？
今天我将做些什么来帮助开发团队实现 Sprint 目标？
我是否看到任何妨碍我或开发团队满足 Sprint 目标的障碍？
在时间框周围增加了清晰度 使用“最多”一词来删除任何问题，即事件的时间框意味着最大长度，但可能更短。
添加到 Sprint Backlog 部分：为了确保持续改进，它包括至少一种团队工作的高优先级方式，在之前的回顾会议中确定。
为增量部分添加了清晰度：增量是一个可检查的，“完成”的工作，支持 Sprint 结束时的经验主义。增量是迈向愿景或目标的一步。
2013 年和 2016 年 Scrum 指南之间的变化
关于 Scrum 值的部分。当 Scrum 团队体现并实践承诺，勇气，专注，开放和尊重的价值观时，透明度，检查和适应性的 Scrum 支柱将栩栩如生，为每个人建立信任。Scrum 团队成员在使用 Scrum 事件，角色和工件时学习和探索这些值。成功使用 Scrum 取决于人们是否越来越熟练地掌握这五个价值观。人们个人致力于实现 Scrum 团队的目标。Scrum 团队成员有勇气做正确的事情并处理棘手的问题。每个人都关注 Sprint 的工作和 Scrum 团队的目标。Scrum 团队及其利益相关者同意对所有工作以及执行工作所面临的挑战持开放态度。Scrum 团队成员互相尊重，是有能力的独立人士。
2011 年和 2013 年 Scrum 指南之间的变化
添加了关于工件透明度的部分。Scrum 依赖于透明度。根据工件的感知状态做出优化价值和控制风险的决策。在透明度完成的情况下，这些决定具有良好的基础。如果工件不完全透明，这些决策可能存在缺陷，价值可能会降低，风险可能会增加。
Sprint Planning 现在是一项活动。其中涉及两个主题：Sprint 可以做什么，以及如何完成所选择的工作。在开发团队预测 Sprint 的产品 Backlog 项目之后，Scrum 团队制定了 Sprint 目标。Sprint 目标在开发团队的工作中创造了一致性，如果没有共同的目标，这些工作就不会出现在单独的计划中。请注意正式包含 Sprint 目标。
产品 Backlog 经过精炼而非整理。精确的产品 Backlog 项目是透明的，足够的理解和粒度足以输入 Sprint 计划和 Sprint 的选择。具有此透明度的产品 Backlog 项称为“Ready”。Ready 和 Done 是两个强化透明度的状态。
Scrum 规定其事件以创建规律性并最小化对未在 Scrum 中定义的会议的需求。所有事件都是时间盒事件，因此每个事件都有最长持续时间。作为容器事件的 Sprint 具有不能缩短或延长的固定持续时间。只要达到事件的目的，剩下的事件就可以结束; 确保花费适当的时间而不会在过程中浪费。
Daily Scrum 作为计划活动的重要性得到了加强。它经常被视为一种状态事件。每天，开发团队应该了解它打算如何作为一个自组织团队一起工作，以实现 Sprint 目标，并在 Sprint 结束时创建预期的增量。会议的输入应该是团队如何实现 Sprint 目标; 输出应该是一个新的或修订的计划，以优化团队在满足 Sprint 目标方面的努力。为此，重新制定了三个问题，以强调团队对个人的影响：
昨天我做了什么帮助开发团队迎接 Sprint
今天我将做些什么来帮助开发团队实现 Sprint 目标？
我是否看到任何妨碍我或开发团队满足 Sprint 目标的障碍？
价值观的概念得到了加强，可以在 Sprint 评论中使用。在 Sprint 评审期间，Scrum 团队和利益相关者就 Sprint 的工作进行了合作。基于此以及 Sprint 期间产品 Backlog 的任何更改，与会者将就可以采取的下一步措施进行协作以优化价值。
2010 年和 2011 年 Scrum 指南之间的变化
开发团队不承诺完成 Sprint 计划会议期间计划的工作。开发团队创建了它认为将要完成的工作的预测，但是随着 Sprint 中的更多知识的出现，预测将会发生变化。
Scrum 没有要求使用刻录图来监控进度。Scrum 仅需要：
Sprint 的剩余工作每天汇总并且已知。
整个 Sprint 都保持着完成 Sprint 工作的趋势。
在使用 Scrum 时，发布计划是一件很有价值的事情，但 Scrum 本身并不需要。
Sprint Backlog 是为 Sprint 选择的 Product Backlog 项目，以及交付它们的计划。不再需要“Sprint Backlog 项目”的概念，尽管这种技术可以制定一个很好的计划。自组织开发团队总是有一个计划。
产品待办事项是“有序的”，而不是“优先”，为产品负责人提供灵活性，以便在其独特情况下优化价值。
添加了 Product Backlog Grooming 的做法。
删除许多提示，可选的做法和技术。
执行创建增量工作的人员团队是开发团队。无论各个团队成员的工作如何，他们都被称为开发人员。
删除了对鸡和猪的参考。
删除了对撤消工作的引用。
Agile & Scrum Basis
Comprehensive Scrum Guide
What are Scrum’s Three Pillars?
What is Agile Software Development?
Scrum in 3 Minutes
What are the 5 Scrum Values?
What is the Evolution of Scrum?
Classical Project Management vs Agile Project Management
Why is Scrum Difficult to Master?
