迭代计划是 Scrum 团队用来启动 Sprint（迭代） 的仪式，执行的好与坏可能将决定本次迭代成功与失败。本文将介绍开好迭代计划会的4大技巧——会前准备、限制会议时间、关注结果而非细节、合理预估。以及一些概念和最佳实践。
一、什么是迭代计划（Sprint Planning）
迭代计划通常是在迭代计划会议上制定，它是 Scrum 框架中的仪式之一，它定义了接下来的迭代中可以交付的内容，以及如何完成各项工作。迭代计划是 Scrum 中用来启动迭代的仪式。迭代计划的目的是定义迭代可交付的增量，以及如何完成各项工作，迭代计划需要整个 Scrum 团队合作完成。
与体育概念中的最后冲刺不同，Scrum 中的迭代要求团队一直保持快速迭代的状态以提供可工作的软件，并且还要求团队不断学习和提高。
二、如何开好迭代计划会议
在 Scrum 中，迭代指的是一个能够将工作计划都完成的固定周期。而在迭代正式开始前，团队需要设置好迭代的相关条件，例如：决定迭代时间周期长度、迭代目标以及从哪里开始行动。
迭代计划会议围绕本次迭代中的待办事项和工作重点展开。如果组织得当，迭代计划会议还能够为团队营造一个充满激情和挑战氛围，并指引团队走向成功；而糟糕的迭代计划会议可能会因为设定不切实际的目标，而导致团队的失败。
- 做什么——Product Owner 阐述迭代目标，以及哪些待办工作项有助于实现该目标。Scrum 团队据此决定在即将开始的迭代中需要做什么，以及做哪些才能实现迭代目标。
- 怎么做——开发团队根据需要交付的迭代目标来规划具体工作。经开发团队和 Product Owner 协商一致后，最终得到一个基于价值和工作量的迭代计划。
- 谁来做——迭代计划必须要有 Product Owner 和开发团队的参与。Product Owner 根据产品的价值取向来制定迭代目标，而开发团队则需要弄清楚是否实现该目标。二者都必须参加，缺一不可，任何一方的缺席都将导致迭代计划无法进行。
- 输入——Product Backload （产品待办列表）是迭代计划中非常重要的一个出发点，因为它提供了可能会成为当前迭代一部分的“基本特征”列表。除此之外，团队还需要查看增量中已完成的工作，以了解进度和剩余工作量。
- 输出——迭代计划会最重要的目的是让明确阐述迭代目标，以及如何实现这个目标。这些内容将体现在 Sprint Backload （迭代待办列表）中。
1.迭代计划会的前期准备
要组织一场合格的迭代计划会需要满足一些基本条件。首先，Product Owner 要做好充足的准备，结合前一次 Sprint （迭代回顾会）中总结的经验教训、利益相关者的反馈以及他们对产品的远景，奠定本次迭代的基础背景。
其次，透明度方面，产品待办列表应是更新后的版本，确保准确。
通常情况下，优化待办列表是 Scrum 中一个可选事件，因为有些待办列表是不需要每次都进行梳理优化的，但对大多数团队而言，最好在迭代计划会议前将团队聚在一起对待办列表进行审查并作出优化。
Tips：如果您的迭代周期为2周，可以试着在迭代中途组织一次待办列表梳理会议。在迭代中停顿一下，看看接下来会的一些计划，这对团队而言是件好事。不仅能够为下一个迭代计划做准备，还能为评估当前的工作提供不同的视角。
2.限制迭代计划会的时间
迭代计划会议的时长应限制在每周两小时内。因此，一个为期两周的迭代，它的计划会议将不会超过两个小时。这叫做“时间盒“，即设定团队完成一项任务所需的最长时间，在这个前提下，进行迭代计划会议。
Scrum （敏捷教练）负责确保会议在规定时间内完成。如果团队在规定时间内达到了满意的效果，就可以认为会议顺利完成。时间限制仅强调最长时间，对最短时间没有限制。
Tips：将迭代计划目标作为迭代计划会的重点，不要将过多的精力放在待办列表的细节上。关注目标而非具体的工作，才能让团队有更多的精力找到实现目标的最佳方案。
3.关注结果而非具体工作细节
在做迭代计划时，团队很容易陷入“细节困境”，纠结于哪个任务应该先做，由谁做，以及完成这项任务需要多少时间等。对于比较复杂的工作，初期掌握的信息有限，且大部分判断都是基于假设。Scrum 是一个完全经验主义的过程，这就意味着很多工作没办法提前规划，而且要通过实践来学习，然后将学习到的信息反馈到整个开发流程中。
迭代待办列表可以用结果导向的思维来编写。用户故事是一种从用户角度描述工作的非常好的方式。如下图所示，用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上，而非观察到的问题。
作为一个<角色>, 我想要<特征>, 以实现<价值>
通过在用户故事中添加清晰、可测量的标准，团队可以清楚地衡量输出结果，知道完成的标准。尽可能提前了解团队应该关注的工作，这样团队中每个人在启动工作时就不至于一无所知。例如，团队可以将无法确定的事情定为需要在迭代切件回答的问题，也好过让其保持不清不楚的状态。
4.强调预估，拒绝猜测
迭代计划需要一定程度的预估，团队需要明确迭代中能或者不能完成的任务，但工作量的预估经常与承诺相混淆。预估本质上是团队根据当前掌握的知识经验做出的预测。衡量工作量大小的方法如故事点、工时，为团队提供了不同的视角来分析和看待问题。但它们并非神器，不能帮助团队在尚未掌握足够信息的前提下发现真相。因此，未知因素越多，预估的正确性就越低。
良好的预估要基于相互信任的环境。在这种环境下，团队可以自由交换信息，在不断的学习和改进中对假设进行验证。如果工作完成后证明前期的预估是错误的，那么以后的预估要么变得大很多，以确保不再出错；要么花更长的时间来进行预估，以避免再次出错。
Tips：团队可以尝试用不同的预估方法，如故事点或工时。因为不同的方法分析问题的角度不同。
三、迭代计划最佳实践
在迭代计划期间，团队很容易陷入“细节困境”，导致他们忘了迭代计划的重点是为了接下来的迭代制定一个“恰到好处”的计划。
迭代计划不应该成为团队的负担，而应该帮团队专注于有价值的结果，并确保团队保持正常的运行轨迹。好的迭代计划通过定义输出的结果和清晰的计划来获得成功，但也要小心过犹不及。
迭代计划中，要关注目标和恰到好处的迭代待办列表，而不是面面俱到的规定迭代中每一分钟的工作计划。接下来，就是确定产品待办列表的顺序，以便团队提前完成迭代目标时能接着进入后续的工作中。
Scrum 是一个旨在解决复杂问题的流程框架，而复杂问题的解决需要一个经验积累的过程（边做边学）。经验积累的过程很难预先计划，所以不要自欺欺人——要承认我们不可能制定完美的计划。相反，可以专注于结果并投入到实际工作中去，哪怕我们正在尝试解决非常困难的问题，启动工作仍可以是一件简单的事情。
以上就是关于如何开好迭代计划会议的分享，希望对你有所帮助。
