故事和史诗的大小应该使用故事点数【原注7】或是理想工作日估算出来，并按优先级排序，这样工作可以分配到各个迭代之中。版本发布规划活动以产品负责人解释待发布版本的目标开始。团队讨论在这样的目标下，需要交付哪些东西，并表明在交付时需要考虑哪些因素。其他要考虑的因素包括风险，以及史诗和故事之间的依赖。高风险、高价值的功能特性应该排高优先级，以早日交付，这样项目可以调整，以应对风险是否会演化成严重问题（比如，我们掌握的技术无法做到我们期望的结果）。依赖关系也许会影响交付的顺序（如果我们先完成这一块，那一块后面做起来容易了）。

版本发布规划活动从团队的速度开始，如果这是第一次版本发布，需要估算团队速度，对于后续的版本发布，此前版本发布时的实际速度可以用来作为参考（除非团队在版本发布之间发生巨大变动）。

刚开始只能猜测估算速度，要想得到更为准确的猜测，要花更长时间来得到结果。简单的方式是：询问团队，让他们估计自己能够在一个迭代内完成多少个故事点数，并在这个数字上做计划。结果可能不准确，但是已经可以作为好的起点。

要对团队的交付能力有更好的估算，得使用更彻底的估算技巧，要知道想得到更准确的结果，得付出更多成本，而且付出的成本不一定能够提供更多价值。James King在自己的网站上提供了一个有用的估算工具包，可供下载。

得到估算速度之后，可用其规划迭代，步骤如下：

    按照优先级顺序，列出故事和史诗，并注明它们的故事点数大小。
    （根据估算活动）判断一个迭代中可以交付多少故事点数。
    考虑团队需要完成的非用户故事工作可能产生的影响，比如在早期的迭代中，由于工具和工作环境不到位，工作效率会受到影响。
    向计划中加入一个新的迭代。
    向迭代中加入故事，直到用掉所有的工作能力。
    询问：是否所有的故事都已经解决、版本发布目标是否达成。
    如果没有，那么向计划中加入新的迭代，并重复步骤5和步骤6.
    一旦所有的故事都已经分配完成，与大家计划进行交流，并征求他们的反馈，看看这些计划是否现实并且可以完成。

这个流程可以通过下图展示：

版本发布规划是一个具备适应性、可调整的计划，它将会随着项目推进而改变。一旦版本发布规划完成，而且大家对之达成共识，它可以用来指导迭代中的工作。版本发布规划也可以用来制作项目的初目标速度图。

迭代规划

在每个迭代的开始，团队根据从已完成工作中得到的经验教训、以及项目所处的更大环境，可以重新规划项目剩余的工作。迭代规划会议有两个主要活动。

    验证、更新版本发布规划
    为当前迭代制定迭代计划

第一个活动中，可以检查当前的版本发布规划，并根据自上次更新来发生的任何变化，更新当前版本发布规划。迭代的开始，是敏捷项目调整的时候，基于项目环境的实际情况，可以改变规划。