今天（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 and Scrum Tool
- for Diagramming, Charting, Infographics, and Business Map, Customer Journey Map, UML, BPMN and more…. () () & () Description