共计 2937 个字符，预计需要花费 8 分钟才能阅读完成。
什么是 Sprint 规划？
Sprint 规划是 scrum 中用来启动 Sprint 的事件。迭代规划的目标是定义 Sprint 可以交付的内容，以及如何完成各项工作。迭代规划需要整个 scrum 团队合作完成。
与体育概念中的最后冲刺不同，scrum 中的‘冲刺’（sprint）要求团队一直保持极速状态以提供可工作的软件，与此同时还需要不断学习和提高。
在 scrum 中，Sprint 是所有工作都得以完成的一段时间。只是在开始行动前，需要设置 Sprint 的相关条件：例如要决定时间周期的长度、Sprint 目标以及从何处开始行动。Sprint 规划会围绕 Sprint 中的应办事项和工作重点展开。如果组织得当，Sprint 规划会还能够为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的 Sprint 规划可能会因为设定不切实际的目标，而导致团队的失败。
- 做什么——Product Owner 阐述 Sprint 目标以及对实现目标有益的 PBI。Scrum 团队据此决定在即将开始的 Sprint 中需要做什么，以及要做哪些才能实现 Sprint 目标。
- 怎样做——开发团队根据需要交付的 Sprint 目标来规划具体工作。经开发团队和 Product Owner 协商一致后，最终得到一个基于价值和工作量的 Sprint 计划。
- 谁来做——Sprint 规划必须要有 Product Owner 和开发团队的参与。Product Owner 根据产品的价值取向来制定 Sprint 目标。而开发团队则需要弄清楚能否实现该目标。二者都必须参与，缺一不可，任何一方的缺席都将导致 Sprint 计划无法进行。
- 输入——Product Backlog 是 Sprint 计划中非常重要的一个出发点，因为它提供了可能会成为当前 Sprint 一部分的“基本特征”表。除此之外，团队还需要查看增量中已完成的工作，以了解进度和剩余工作量。
- 输出——Sprint 规划会议最重要的目的是让团队阐述 Sprint 目标，以及如何实现这个目标。这些内容将体现在 Sprint 的 Backlog 中。
Sprint 规划会的前期准备
要举办一场精彩的 Sprint 规划会需要满足一些基本要求。Product Owner 要做好充足的准备，结合前一次的 Sprint Review 会议中总结的经验教训、利益相关者的反馈以及他们对产品的愿景，奠定 Sprint 的基础背景。透明度方面，Product Backlog 应是更新后的版本，确保清晰精准。Backlog Refinement 是 scrum 中一个可选事件，因为有些 backlog 不需要进行梳理优化的。但对大多数团队而言，最好在 sprint 规划会前将团队聚在一起对 backlog 进行 review 并做出优化。
专家提示：
周期为 2 周的 Sprint，要在中期举行一次 backlog 梳理会议。跳出当前的 Sprint 来思考下一个对团队来说大有裨益。这样不仅能够为 Sprint 规划做准备，还可以为评估当前的工作提供不同的视角。
限制 Sprint 规划的时间
Sprint 规划的时长应限制在每周两小时以内。所以，一个为期两周的 Sprint，其规划会议将不会超过两个小时。这叫做“timeboxing”，即设定团队完成一项任务所需的最长时间，在这个前提下，进行 Sprint 规划。Scrum Master 负责确保会议在规定时间内完成。如果团队在限定时间内达到了满意的效果，就可以认为会议顺利完成。时间限制仅强调最长时间，对最短时间没有限制。
专家提示：
将 Sprint 目标作为 Sprint 规划的重点，不要将过多的精力放在 Backlog 的细节上。聚焦目标而非具体的工作，才能让团队有更多的精力找到实现目标的最佳方案。
聚焦结果而非具体工作
在做 Sprint 规划时，团队很容易陷入“细节困境”，纠结于哪个任务应该先做，由谁做，以及完成这项任务需要多少时间等。对于比较复杂的工作，初期掌握的信息有限，且大部分判断都是基于假设。Scrum 是一个完全根据经验的过程，这就意味着很多工作没办法提前规划，而是要通过实践来学习，然后将学习到的信息反馈到整个开发流程中。
Sprint 目标以一个比较高的水平对 Sprint 的目标进行阐述，而 backlog 列表也可以用结果导向的思维来编写。用户故事是一种从用户角度描述工作的非常好的方式。如下图所示，用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上，而非观察到的问题。
通过在用户故事中添加清晰、可测量的结果，团队可以清楚地衡量输出结果，知道什么时候才算完成。尽可能提前了解团队聚焦的工作，这样团队中每个人在启动工作时就不至于一无所知。例如，团队可以将无法确定的事情定为需要在 Sprint 期间回答的问题，也好过让其保持不清不楚的状态。
专家提示：
无法确定某事和让其保持不清不楚的状态是两回事。不要忽视未知事件，因为它们就是团队必须脚踏实地完成的艰苦工作。但也不要使用含糊不清的描述来掩盖或隐藏它们。相反，当你不了解某些事情时，要认清自己的无知，并将其列为需要进一步了解的工作。
预估是必要的，但不代表要假装了解未知事项
Sprint 规划需要一定程度的预估。团队需要明确 Sprint 中能或者不能完成的任务，即：预估工作量和实际工作量。工作量的预估经常与承诺相混淆。预估本质上是团队根据当前掌握的知识做出的预测。衡量工作量大小的方法如故事点（story points）和 T 恤尺码分类法（t-shirt sizing）分别为团队提供了不同的视角来分析和看待问题。而它们并非神器，不能帮助团队在尚未掌握足够信息的前提下发现真相。因此，未知因素越多，预估的正确性就越低。
良好的预估要基于相互信任的环境，在这种环境下，团队可以自由交换信息，在不断的学习和改进中对假设进行论证。如果工作完成后证明前期的预估是错误的，那么以后的预估要么变得大很多，以确保不再出错；要么花更长的时间来进行预估，以避免再次出错。
专家提示
团队可以尝试用不同的预估方法，如 T 恤尺码分类法（t-shirt sizing）或故事点（story points）。因为不同的方法分析问题的角度不同。
Sprint 规划最佳实践
Sprint 规划期间，团队很容易陷入“细节困境”，导致他们忘了 Sprint 规划的重点是为接下来的 Sprint 制定一个“恰到好处”的计划。规划不应成为团队的负担，而应该帮团队专注于有价值的结果，并确保团队保持正常的运行轨迹。好的 Sprint 规划通过定义输出的结果和清晰的计划来获得成功。但也要小心过犹不及，Sprint 规划中，要聚焦目标和恰到好处的 Sprint Backlog，而不是面面俱到的规定 Sprint 中每一分钟的工作计划。接下来，就是确定 Product Backlog 的顺序，以便团队提前完成 Sprint 目标时能接着进入后续的工作中。
Scrum 是一个旨在解决复杂问题的流程框架，而复杂问题的解决需要一个经验积累的过程（即边做边学）。经验积累的过程很难预先计划，所以不要自欺欺人——要承认我们不可能制定完美的计划。相反，可以专注于结果并投入到实际的工作中去，哪怕我们正在尝试解决非常困难的问题，启动工作仍可以是一件易事。
文章来源：Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。
