“Scrum的会议太多、开会时间太长！”——我常常听到团队这样批评Scrum。大部分自行学习和实施Scrum的团队，往往都会把Scrum会议开得过长。我曾经见过有团队开了一整天的迭代计划会议（迭代周期为2周），这样的迭代计划确实是太长。
今天我来分享一下如何高效实施迭代计划会议，以帮助这些团队提高计划效率。
传统团队实施迭代计划的常见问题
传统团队在刚实施Scrum时，往往会按照传统的项目计划方式实施迭代计划会议：- 在会上，详细讲解每一条需求的细节。
- 在会上，针对每一条需求，做任务分解和工作量估算，并分配到具体的开发人员。
- 在会上，汇总得到完整的迭代进度计划。
这样一来，就导致了两个结果：
第一，会议时间过长。比较典型的例子是：花一整天时间来开一个迭代周期只有两周的迭代计划会议。
第二，把目标分散到个人身上，使得团队成员在迭代中只关注自己的目标，而不关注团队整体目标，团队变成了一盘散沙。
因此，这种传统项目计划是以项目经理为核心的计划方式，不合适于敏捷团队，该抛弃掉。
如何高效实施迭代计划
对于时长为两周的迭代，我们通常只需要要半小时就能完成迭代计划。
具体方式如下：
1 做好Backlog梳理
需求讲解、技术方案分析等工作应该在迭代计划会议前完成，而不应在迭代计划会议上进行。Scrum中的“Backlog梳理”活动，就是完成这项工作的。
在本迭代中，我们在开发和交付本迭代工作的同时，还要完成下迭代的Backlog梳理工作。这样在下个迭代的计划会议前，团队便已经熟知每条需求细节。
请注意：在迭代计划会议前团队就已经熟知需求细节，是高效实施迭代计划的前提。
2 基于团队容量的迭代计划过程
我们在实施迭代计划时，采用的是类似于“填土游戏”的方式，以真正基于团队能力规划迭代需求量。
1）设计团队容量表格
我们的迭代计划，是基于团队容量（团队一个迭代能够完成的工作量）来进行的。为了形象地展示团队容量，我设计了团队容量表格这个工具。
假设：在一个web开发团队中，前端工程师为2人，后端工程师为4人，测试工程师为2人，迭代周期为1周（5天）。我们可以把团队容量表格设计成图1的样子。
图1 团队容量表格
2）往团队容量表格中填充迭代需求
现在，我们可以往团队容量表格中填充需求了。
对于每一个需求，我们分析前端开发工作量、后端开发工作量和测试工作量，以及考虑团队如何通过协作来尽快完成，然后把它填充到表格中。
假设：第一个需求，需要1天的前端开发工作量（1名前端工程师）、2天的后端开发工作量（可以由2名后端工程师共同完成）、0.5天的前后端联调以及1天的测试工作量。
图2 填充需求1后的团队容量表格
如图2所示 ，我们可以把需求1填充到表格中。
接下来，我们可以继续分析和填充下一条需求。
我们在填充需求时，要注意以下几点：
- 按照需求优先级，一条一条地分析和填充。
- 要预留出一定的裕量，以应付突发事件以及完成下迭代的Backlog梳理。
3）何时停止以及如何处理异常
何时该停止填充？并没有严格的规定。一般来说，如果团队容量表格基本填满了，就不会再填入新的需求。
但是，往往事情并不会那么理想地发生。所以我们还会以如下方式来处理异常：
- 如果有部分职能已经填满，而部分职能仍然存在空闲，该怎么办？这种情况下，我们可能会进行跨职能的工作调剂，例如：让开发人员也承担一部分测试工作。也可能会安排一些只需要空闲职能就能完成的工作，例如：补充接口自动化测试用例。
- 如果团队容量表格基本填满，仍然不能满足PO的期望，该怎么办？例如：PO期望本迭代能完成一个包含7条需求的完整价值闭环交付版本。但按照团队容量，只能填充6条需求。这时候，PO和团队共同来审视业务上的紧迫性以及团队完成全部7条需求的可行性，协商达成一致。结果可能是：团队通过加班来完成全部7条需求，并在本迭代结束时交付一个可用版本。也可能是：在下迭代优先完成剩下的1条需求，并在完成后立刻交付一个可用版本。
该何时确定人员的工作安排
传统团队在实施迭代计划时，会习惯性地把工作分配到人。在前面的章节，我已经说过这种做法的危害。
那么该在何时确定人员的工作安排呢？应该在每日站会上，在规划每个需求的开发工作时，明确团队如何分工和协作，以尽快完成需求的开发和交付。
您有何经验
您是如何组织召开迭代计划会议的？对于为期两周的迭代，您的迭代计划会议需要花费多长时间？您会在迭代计划会议上把工作任务分配到个人吗？
欢迎在评论区留下你的观点。
作者
李洁（Jerry Li）
CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
