敏捷开发中，如何做好Sprint规划？

Sprint规划会围绕Sprint中的应办事项和工作重点展开。如果组织得当，Sprint规划会还能够为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的Sprint规划可能会因为设定不切实际的目标，而导致团队的失败。

什么是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是一个旨在解决复杂问题的流程框架，而复杂问题的解决需要一个经验积累的过程（即边做边学）。经验积累的过程很难预先计划，所以不要自欺欺人——要承认我们不可能制定完美的计划。相反，可以专注于结果并投入到实际的工作中去，哪怕我们正在尝试解决非常困难的问题，启动工作仍可以是一件易事。

本文由 @微澜 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议