敏捷计划的目的是以迭代的方式为产品开发的综合问题——在哪段时间内使用哪些资源来得到哪些功能——寻找到最佳解决方案。
敏捷估算和计划方法可以成功找到这样的解决方案的原因包括：
计划是在不同层次上做出的，并且频繁地重新计划；
计划是根据特性而不是根据任务做出的；
首先估算大小，然后根据大小的估算值推算出持续时间；
小故事保持工作的流动，而且每次迭代结束时会消除未完成的工作；
在团队层次而不是个人层次对进度进行度量；
承认不稳定性并为之做计划。
成功进行敏捷估算和计划的12条知道原则如下：
1、让整个团队参与
某些特定活动的主要职责可能会落在某个人或某个团队的身上，例如确定需要优先级主要是产品负责人的职责，但是，在追求可能具有最高价值的项目时，整个团队都应该参与进来并做出承诺。团队成员分担的职责越多，团队可以共享的成功也就越多。
2、在不同层次上进行计划
不要误认为发布计划会让迭代计划没有用，反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，各有其特定的用途。
3、使用不同度量单位，让对大小和持续时间的估算保持独立
让对大小和持续时间的估算保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估算大小，再使用速度把大小转换到持续时间是完全这一工作的好办法。
4、使用功能或者日期来体现不确定性
没有哪个计划是确定的。要确保在你指定的任何发布计划中都包含对不确定性的体现。如果新功能的数量是固定的，就把不确定性表示为一个日期范围。如果日期是固定的，就需要在要交付的明确功能上表示出不确定性。当不确定性比较大的时候，就是用较大的单位（例如迭代、月，然后是季度）。
5、经常重新计划
利用每次新迭代开始的时候评估当前发布计划的相关度。如果发布计划是根据过时的信息或者现在被证实为错误的假设制定的，就更新它。使用重新计划的机会来保证项目总是瞄准着为公司交付最大价值的方向。
6、跟踪进度并沟通
许多利益干系人都会对项目的进度很感兴趣。通过经常发布关于团队进展的、简单而易于理解的指示器来让他们了解进度。燃尽图和其他让人一眼就能看明白的项目进度指示器是最好的。
7、承认学习的重要性
由于项目既能向产品增加新能力，又能产生新的知识，所以必须更新计划来包含这些新知识。随着我们更多的了解客户的需要，新的特性会增加到项目中，随着我们更多地了解我们使用的技术或协作的情况，我们会调整对进度率的期望和希望采用的方法。
8、计划具有适当大小的特性
在不久的将来就要增加的功能应该分解成相对较小的用户故事——往往是只需要1~2天，最多不超过10天的故事。我们最善于估算大小处于一个数量级以内的工作。让用户故事都处于这一范围内，可以让我们在估算和计划中付出的工作量和得到的准确度达到最佳的组合。
9、确定特性优先级
按照让项目总价值最高的顺序来开发特性。确定优先级时除了考虑功能的价值和成本，还要考虑他能带来的学习效果以及开发他能够减少的风险。
10、最好的估算和计划来源于事实
只要有可能，就要把你的估算和计划建立在现实基础上。
11、保留一些松弛度
尤其是在计划依次迭代的时候，不要计划用掉所有团队成员100%的时间。就像公路在达到100%容量的时候会完全停滞一样，如果将所有人的时间都计划成满负荷工作，开发团队的进展也会减慢。
12、通过前瞻性计划协调多个团队
在涉及多个开发团队的项目中，应该通过滚动性前瞻计划来协调它们的工作。通过提前观瞻以及把特定的特性分派到即将到来的特定迭代，团队间的依赖就可以很好地计划和调节。
