Bruce有话说
2020年新版Scrum指南中引入了冲刺目标（Sprint Goal）。作为团队对Sprint的一个承诺，理解好承诺的作用和目的，而不是仅仅当作一个文字游戏，才能够理解Scrum的精髓。这其实就是我们经常说的要Being Agile，而不要停留在Doing Agile上面。最近在辅导团队的时候，总能发现Team还是停留在Doing，Sprint计划会像是走形式，而Sprint Backlog的创建和管理也很随意。每日Scrum开不开都可以。这是为什么呢？Scrum框架本身很简单，如何能团队真的理解并有热情去用好Scrum呢？当看到Scrum Pattern这篇文章的时候，我眼前一亮。小到工作的目的，大到人生的目标，Goal是能够唤起我们内驱力的最重要的一个东西。明确的目标自然会给人们带来使命感。Sprint Goal作为团队实际工作中的目标。他是Scrum Team在Sprint级别的承诺。他也会在如下方面帮助我们：
- 理清楚PIBs和SBIs之间的关系？
- Sprint Goal可作为团队内部对齐的一个手段。避免团队每个人眼里只有独立的一个一个任务而没有整体目标，拒绝合作。
- 当Sprint的计划会因为团队工作中涌现新的想法，而导致工作量的变化，从而需要重新计划的时候，如何保证调整是正确的呢？Sprint Goal就该出场了。
- Sprint Backlog是团队的决定，PO无从干涉，但是PO可以用Sprint Goal来影响团队在Sprint中的选择和优先级排序。
- Sprint Goal是sprint计划会的关键输出之一。团队要能够用来说明如何能实现这个目标，如何证明实现了目标，才能说明团队有信心来完成当次Sprint。而很多时候我们的sprint计划会更多是走一个过场、任务宣读会。而缺少了团队和PO之间的一个承诺。
- 如何能保证daily scrum中面对涌现的突发情况做的调整不会跑偏？Sprint Goal是那个不灭的灯塔。
说了这么多接下来就让我们一起认识一下Sprint Goal吧。希望本文能够引发你更多的视角和思考。
正文
你已经准备好开始Sprint了，你正在Sprint planning meeting中进行计划。
✥ ✥ ✥
Sprint的目标是向干系人交付价值。然而，简单地遵循Sprint待办事项列表(SBIs;例如，任务)不一定会创造最大可能的价值。
因为团队根据单个任务或可交付成果来安排其工作计划，所以很容易在生产阶段挑选单个项目并单独处理该项目。然而，这冲淡了个人之间的互动带来的创新，这些个人之间的互动为工作带来了不同的视角。隔间墙可能成为持续交流见解的障碍，这些洞见不仅对一个开发人员很重要，而且对许多开发人员(开发团队成员)或整个团队都很重要。团队精神受到损害。
团队可能需要部分地重新规划正在进行的Sprint，以确保团队在Sprint结束时向干系人交付价值。新的工作项可能会从团队的最新洞见中涌现出来，团队应该相应地更新其计划。如果团队遵循最初的工作计划，它可能不会创造最大的价值。另一种常见的情况是，在Sprint进行到一半的时候，团队显然不会完成Sprint Backlog中的每一个SBI。这通常是因为完成SBI所需的工作内容被扩大了。如果可能的话，团队仍然希望交付价值，这可能需要重新规划。而重新规划Sprint的工作需要深思熟虑和时间。
另一个场景是，团队需要关于如何实现产品待办列表(PBI)的重要技术知识，以知道如何满怀信心地开发它。开发人员(甚至产品负责人)可能需要一个技术原型来验证建议的架构或学习某些技术的性能特征。虽然PBI应该识别这样的工作，但它的不确定性要求团队专注于获取知识，而不是完成所有计划的工作。技术原型成为Sprint成功的关键路径项目。
在某些情况下，最大的价值可能不是明确的产品待办事项列表项。举个例子，对团队来说最大的价值是增加每个Sprint的收入，团队为此投入了一个产品待办事项列表项目。另一方面，有时Sprint的大部分价值很大程度上来自于许多关键PBI中的一个。
因此：
Scrum团队承诺在Sprint期间创造一个简短的价值声明。这成为Sprint中所有工作的焦点。
整个Scrum团队共同创建了Sprint目标。产品负责人自然会指导Sprint目标的创建，因为他或她对产品愿景的下一步以及如何创造最大价值有着最好的看法。Scrum团队应该将Sprint目标视为可以实现的目标。
开发团队创建一个常规产品增量来满足每个Sprint的目标。
✥ ✥ ✥
Scrum团队可以使用Sprint目标来为Sprint选择pbi，但在某种意义上，Sprint目标甚至比单个pbi的总和更重要。Sprint目标在pbi中创建一致性，帮助创建有价值的产品增量。对于产品待定项列表，一个好的初始方法是将其表达为Sprint目标列表，产品负责人和开发团队一起将其细化为PBIs。
自治团队的成员必须能够管理自己以实现他们的目标，而开发人员有序工作计划指出，开发团队必须自由地安排他们的产品阶段性工作，无论他们认为怎样合适。Sprint目标是产品负责人能够影响开发团队执行其工作的潜在顺序的唯一机制(通过从Sprint目标传达的重要性来推断紧迫性)。但是这里需要再次强调，必须得到开发人员的同意。
在Sprint计划会期间，Scrum团队决定他们在Sprint结束时想要达到的目标;简而言之，这就是Sprint目标的目的。开发团队定义了如何通过创建Sprint Backlog来完成这个Sprint目标的细节。如果开发团队认为他们无法完成Sprint目标，那么应该与产品负责人一起完善Sprint目标。Sprint计划会的一个关键输出是：开发团队应该能够解释如何能够实现Sprint目标，以及如何知道已经实现了目标。实现目标的能力来自于对事先工作的全面理解，这提高了团队在Sprint中实际实现Sprint目标的可能性。
开发团队致力于Sprint目标。这个Sprint目标可以帮助统一开发团队(参见目的的统一)，并且它有助于建立干系人和团队间的信任。
Sprint目标应该对团队可见;例如，把它放在Scrum Board或其他信息辐射器上。
开发团队在Sprint期间持有Sprint Backlog为当前状态，以支持实现Sprint目标。Sprint Backlog的进展(如Sprint Burndown Chart所示)就像Sprint期间在足球场上的进展:尽管每一码的进展都让球更接近终点，但价值来自于目标。不过有时候在没有完成所有sbi的情况下完成Sprint目标(以某种方式)是可能的。这有助于团队处理突发事件，并让开发人员在每天的每日Scrum中灵活地更改他们的工作计划。例如:涌现出来的障碍会威胁到开发团队完成Sprint Backlog的交付。在这种情况下，团队自动地将Sprint目标作为“B计划”，而无需花费长时间重新规划。卡内基梅隆大学[1]进行的一项研究报告称，提前做好准备的团队比没有做好准备的团队处理中断的能力强14%。有准备的团队比没有准备的团队完成不间断任务的速度快43%。这是一种为计划外的事情做准备的心态:当它们发生时，团队可以转向一个新的配置来处理它们，而无需外部指导。
理论上，在每个Sprint只完成一小部分PBIs的情况下，重复实现Sprint目标是可能的。这应该是不常见的，因为Sprint Backlog应该与Sprint目标保持一致;如果不是，价值流就有严重的问题。
速率(参见关于速度的注释)有助于团队理解他们做的事情是否正确(假设做的事情正确会增加你的速率)。Sprint目标帮助团队确保他们正在做正确的事情。它是关于理解团队所做的事情的“为什么”，以便在事情发生变化时保持专注。
Jeff Sutherland补充道，除了保持团队专注之外，Sprint目标还鼓励了蜂拥而至(参见SWARMING):我们能让每个人一起做一件事吗? 他描述道:
2007年，Palm在硅谷开发Web操作系统，后来被惠普收购。在一开始的Sprint到Sprint之间，团队一直做得很好，直到他们在几个Sprint中遇到了障碍。PBIs没有完成。开发人员士气低落，早早就回家了。我被请来，让产品负责人和scrummaster花了一个小时的时间采访团队成员，询问他们为什么会失去动力。我们发现，他们不明白他们努力工作在低技术水平的PBIs的原因。
我们花了一个下午的时间来清理Product Backlog，以显示高层描述和分解层次之间的清晰联系。一旦开发人员明白Sprint的目标是将Web操作系统的性能提高10%，他们就会被激励去完成低技术水平的故事，并且迭代速率恢复到正常水平。
理解为什么要实现PBIs对于开发人员来说是至关重要的，特别是对于那些在看不到工作原因时更喜欢去冲浪的专家级别开发人员来说。
Sprint目标通常与产品价值有关。团队可以根据过程目标来定义Sprint目标——例如，通过结对编程来完成所有编程，或者每天按时参加每日Scrum。
不断地朝着Sprint目标前进能够激励团队达到更高的参与度;相反，幸福指标可以是定义或建议Sprint目标的有效工具。
2001年，Ken Schwaber和Mike Beedle是第一个描述Sprint目标的人。([2], p. 48).
[1] Bob Sullivan and Hugh Thompson. Gray Matter. “Brain, Interrupted.” In New York Times, 5 May 2013, page SR12, http://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html (accessed 2 November 2017).
[2] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 48.
Picture credits: Shutterstock.com.
