几周前，我参加了一个很痛苦的迭代计划会。类似的会议你可能也参加过，团队竭尽所能试图分析出本次迭代所要完成的所有任务，并就每一个任务具体需要花费多少小时进行无休止的争论。

然而这种级别的细节讨论其实是不需要的。

迭代计划会的目的是从产品列表中挑选出本次迭代要完成的条目，并对如何完成有一个大致的想法，达到这个目的并不需要团队了解每一个任务，当然更不需要团队知道某个任务是需要花费4小时还是5小时。

请不要回答“取决于”

我经常会被问到一个团队应该花多长时间召开迭代计划会，与其闪烁其词的说“这取决于。。。”或者“时间刚好足够计划好本次迭代的内容”，有一个更实用的方法决定你是否花了合适的时间在迭代计划会上。。。

通过对成功团队的迭代计划会的多年观察，我建议团队应该在计划会上明确三分之二的本次迭代的任务，也就是本次迭代另外三分之一的任务应该在迭代过程中进一步明确。

一个例子

比如：迭代结束时，团队完成了60个任务，交付了一些产品条目，我的建议是大约三分之二的任务（这个案例中，就是40个）应该在计划会上确认，剩下的三分之一（20个任务）应该留在迭代过程中发现。

当然，如果ScrumMaster在计划会的时候关上门，要求团队更深入更长时间的思考，团队也许可以识别出另外10个任务。但是代价呢？这其实是不值得的，计划会的目的是从产品列表中选出本次迭代要完成的产品条目，第二目标是尽快开始和结束会议。

如果你的团队已经习惯于安排的很满的迭代，也许你需要稍微后退一步，让你的迭代安排不那么满，在《敏捷估算和计划》这本书里，我将这个称之为“计划外时间”。

我的观点是，团队在计划会上应该快速识别他们需要做的最重要的事情，一些小的任务可以先忽略，有一些任务也许团队可以耗时耗力想出来，但是不值得，因为反正团队也不能识别出所有的任务。

开会，散会，干活。

为计划外的工作留下资源

留一些资源给计划会上没有深入分析的任务，留一些资源给计划会上讨论了但是可能会变大的任务，留多少资源呢？给一个预估值，下一个迭代时调整这个预估值，经过几个迭代之后，这个估算值就会接近准确。

注意，我说的是迭代内的任务数，而非小时数，团队在计划会上没有考虑到的任务会变成一些更小的任务，不会有人忘记“实现某个功能”，团队只是未考虑到与之相关的更小的任务。

你认为呢？

本文转自：敏捷工具Leangoo.com