1 发布规划基础
发布计划是覆盖了比一次迭代更长时间范围的高层次计划。对大多数开发小组来说，每3-6个月会进行一次发布，但是根据开发的软件类型不同，更频繁或者更少的发布也不少见。最简单的情况下，发布规划可以说是微不足道的：用预期的速度乘以计划得迭代次数，然后选择用户故事，让他们的规模估计值之和充满这次发布。
发布计划并不需要精确说明在每次迭代中要完成那些工作。实际上，很少会需要这一水平的细节。对大多数项目而言，指出第一次迭代中要处理的用户故事就足够了，可以把剩下的用户故事留到以后再按优先级分配到其他的迭代中。
发布规划是一个迭代的过程，首先要确定产品所有者对这个项目的满意条件。这些条件通常包括了进度、范围和资源方面的目标。如果无法规划一个项目来满足最初的满意条件集，就需要重复规划过程，看是否能够满足一个缩小了的满意条件集，这就需要重复规划过程，看是否能够满足一个缩小了的满意条件集；不然的话，也许可以晚一些交付某些要求的功能，或者采用一个更大的开发小组。
一旦建立了发布计划，不要把它挂在墙上发霉。通常要在每次迭代开始时更新它。
2 迭代规划
与发布计划不同，迭代计划更仔细的审视单次迭代中的特定工作。迭代计划所看到的范围不会超出一次迭代，而不是像典型的发布计划那样达到3-9个月。在发布计划中相当大的用户故事在迭代计划中被分解成任务。对每项任务，都要按照完成该任务所需要的理想小时数进行估计。
概括起来有两种进行迭代规划的方法：速度驱动的方法和承诺驱动的方法。这两种方法有很多相同的步骤，而且常常会建立起一样的迭代计划。
3 选择迭代长度
大多数敏捷开发小组采用2周或4周的迭代长度。没有适用于所有小组的绝对正确的迭代长度，每个小组都应该考虑自己所处的独特环境，选择对自己合适的迭代长度。进行这个决策时需要考虑的因素包括：
1）正在处理的发布的时间长度：发布时间更短的项目需要更短的迭代长度，以便有更多的机会进行展示软件，度量开发进度，以及调整优先级和开发计划；
2）不确定性的多少：不确定性越多，迭代应该越短，以便有更多的机会获得客户反馈；
3）获得反馈的难以程度
4）优先级可以保持多久不改变：一个迭代中完成的功能优先级不变很重要，同时迭代周期越长，想法转变为可用软件的时间就越长，需要综合考虑；
5）不用外部反馈自行工作的意愿的强弱：接受外部反馈的频率越低，就越有可能误入歧途，造成的损失也就会越大；
6）迭代的系统开销：每次迭代都会有成本，例如完成的回归测试成本，需要考虑在内；成功的敏捷开发小组的目标之一就是减少每次迭代的系统开销；
7）紧迫感的产生有多快：选择一个合适的迭代长度，让小组感受到的压力更平均。
4 估计速度
有3中估计速度的方法：
1）如果有历史平均值的话，可以使用它们。不过需要考虑开发小组，使用的技术，针对的领域，产品所有者，使用的工具，工作环境，估算人等方面有没有显著的变化；
2）可以推迟对速度的估计，直到进行了几次迭代，这通常是最好的选择；
3）通过把一些用户故事分解成任务，看看多少任务可以充满一次迭代来对速度进行预测，这一个过程与迭代规划很相似。
无论采用哪种方法，都应该以一个范围来给出对速度的估计值，这个范围反映了估计值中蕴含的不确定性。不确定性锥形为要使用的范围大小提供了建议。
5 为不确定性缓冲计划
大多数项目都包含大量的不确定性。项目小组简历的进度表和最后期限中往往没有完全反应这种不确定性。有时候，如果这种不确定性非常大或者非常显著，就需要在估计项目持续时间的时候采取一些额外的步骤。这些不确定的情况可能包括：提前很多进行项目规划、项目必须绝对满足最后期限，同时交付一组相当严格的功能集，项目是外包的，需求仍然处于非常表面的层次，或者在日期出错时会产生严重的影响等。
功能缓冲区和进度缓冲区是两类常见的缓冲区，当确定了项目中所有需求的优先级，然后发现可能不能交付所有功能的时候，就要建立一个功能缓冲区。例如，敏捷开发过程DSDM建议把一个项目中的30%的工作看做是可选的，从而为项目建立功能缓冲区。如果时间不够用，可以通过放弃功能缓冲区中的事项来达到进度表的时间要求。
另一方面，可以在进度表中包含一定量的时间来建立进度缓冲区，这个时间的量反映了蕴含在项目规模中的不确定性。可以通过同时估计每个用户故事具有50%可能的规模和具有90%可能的规模来构造进度缓冲区。通过对每对50%和90%估计值采用平方和的平方根公式，可以估计出合适的进度缓冲区大小。
项目应该用功能缓冲区来预防功能不确定性，用进度缓冲区来预防进度不确定性。可以把功能缓冲区和进度缓冲区结合起来。实际上，这常常是个好办法，因为它可以让每个缓冲区的规模都更小。
6 规划多小组的项目
敏捷开发项目倾向于在开发大型项目的时候避免使用很大的开发小组，而是使用多个小组。当有多个小组工作于一个项目时，他们就需要相互协调工作。有4种帮助多个小组共同处理一个项目时很有效的方法：
1）小组应该为他们的估计建立一个共同的基础。所有小组都应该同意按照相同的单位进行估计，要么是故事点，要么是理想日。他们还应该通过对已小组故事形成一致的估计值来对使用的单位的含义达成一致；
2）当多个小组需要一起工作的时候，尽早给他们的用户故事增加细节常常很有帮助。进行这一个工作的最佳办法是确认产品所有者对用户故事的满意条件。这些满意条件就是一旦完全实现了这个故事，就可以显示为真的那些事；
3）在发布规划过程中结合一个滚动前瞻计划，可以让多个小组收益。滚动前瞻计划简单地向前看几次迭代，通过共享在不久的将来每个小组分别会处理哪些工作的信息，让小组之间可以协调工作。
4）在具有很多小组件依赖性的高度复杂项目中，把馈送缓冲区结合到计划中是有益的。估计缓冲区是在计划中的一段时间，可以避免一个小组推迟交付导致另一个小组推迟启动。
一般可以按照说明这些方法的顺序把它们纳入项目中，不过也可以按照所希望的任何顺序来使用它们。