敏捷计划的目的是以迭代的方式为产品开发的综合问题，在那段时间内使用那些资源来得到哪些功能，去寻找到最佳解决方案。敏捷估算和计划方法可以成功找到这样的解决方案的原因包括：计划是在不同层次上作出的，并且频繁的重新计划；计划是根据特性而不是根据任务作出的；首先估算大小，然后根据大小的估算值推算出持续时间；小故事保持工作的流动，而且每次迭代结束时会消除未完成的工作；在团队层次而不是个人层次对进度进行度量；承认不确定性并为之做计划。
敏捷估算和计划价值分析：
无论软件开发项目的规模如何，估算和计划对于项目的成功都是至关重要的。估算与计划并不仅仅是决定一个恰当的最终期限和进度表，而是对价值的探求.
1.减少风险
2.降低不确定性
3.提供更好的决策支持
4.建立客户信任
5.传递信息
计划失败原因分析：
1.基于活动而不是基于特性进行计划：基于活动的计划常导致项目实际开发超出计划表，有些团队会试图通过不恰当地降低质量来节省时间，有些团队会制定变更控制策略来限制产品变更。主要因素包含：活动不会提前完成；延误随进度表传递；活动不是互相独立的。
2.多任务处理导致更多的延迟：同时处理多个任务，多任务会对生产效率产生可怕的影响。当项目中开始有些活动被延期的时候，多任务处理往往变成了问题。
3.不按优先级开发特性：不按照特性的优先级顺序进行开发，因此某些被放弃的特性可能反而比所交付的特性更具有价值。
4.忽视了不确定性：忽视了与产品相关的不确定性，比如我们不能指望一开始就确定项目进程中需要的所有活动，但我们制定的计划中往往无法意识到这一点。应对不确定性的最佳方法是迭代。
5.把估算当作承诺：如果项目团队或者利益干系人把估算当作了承诺，传统的计划方法就会出现问题。在做出这样的承诺之前，团队需要对大量的商业因素和风险进行评估，并且不要把所有的估算都当成是隐性的承诺。
如何估算大小：
两种度量大小的方法：故事点和理想时间。
故事点：故事点是对用户故事大小的相对度量，将要进行的工作大小进行估算，项目的持续时间通过求取项目的总故事点数，再除以小组的速度而推算出来的.
理想时间：理想时间不是耗用时间，使用理想人天估算，就只需考虑完成这个用户故事所需要的时间，最好只为每个用户故事分配单一的估算值。应该把所有需要的时间加在一起，说某个用户故事需要九个理想人天，而不是说他需要四个程序员人天、两个测试人员人天和三个产品负责者人天。
在故事点和理想人天之间进行选择：
故事点的优势是可以帮助促进团队的跨功能行为。此外，由于故事点是更为纯粹的对大小的估算，因此即使团队在技术上或是领域知识上取得了进步，也并不需要重估他们。如果一个团队成员认为某件事情需要4个理想人天，而另一个成员认为只需要1个理想人天，也许他们都是对的，但是他们缺乏讨论的共同基础，无法建立一个单一的估算值。
理想人天的优势在于更容易向团队之外的人进行解释，以及更容易开始。
我的倾向是使用故事点。使用故事点进行估算的优点更有说服力。如果团队对单纯的大小进行估算存在困难，可以让他们用一下人天开始估算，然后再让他们转化到故事点上。更多的问“这个功能的大小与我们刚才估算的那个相比怎么样？”而不是去问“它会需要多少个零小人天？”大部分团队几乎不会注意到这种渐进式的转变，而当他们意识到的时候，他们已经是在用故事点而不是理想人天进行思考了。
估算方法：
四种最常用的估算方法是：
专家意见：如果你想知道一件事需要多长时间，去问问专家。在基于专家意见的估算方法中，专家根据他自己的直觉给出估算。根据专家意见进行评估的一个好处在于他通常不需要太长时间。根据专家意见进行评估的一个好处在于他通常不需要太长时间。
类比：当用这种方式估算时，你不必把所有用户故事都按一个基线或是通用的参照物进行比较，而是把每个新的用户故事与那些已经估算过的用户故事进行比较。这称为三角测量。
分解：分解是指将一个用户故事或者特性分解为更小、更容易估算的部分。不过当分解太过时，不仅忘记某项任务的可能性会增加，而且对于大量小任务都估算值求和也会出现问题。
计划扑克：要得到一个估算值，我们除了可以依赖专家意见、类比和分解，还可以依赖计划扑克。计划扑克是一个有趣而有效的方法，它结合了上述三种方法。在计划扑克中，每个估算者有一叠写着有效估算值的卡片。每讨论一个功能，每个估算者就选择一张代表他的估算值的卡片。所有的卡片都会同时展示出来。团队对估算值进行讨论，重复这个过程直到团队的估算达成一致。
不确定因素如何处理：
大多数项目都包含大量的不确定性。项目团队建立的进度表和最后期限中往往没有完全反映这种不确定性。有些时候，如果这种不确定性非常大或者非常显著，就需要在估算项目持续时间的时候采取一些额外的步骤。这些情况可能包括：提前很早就进行项目计划、项目必须绝对满足最后期限（同时交付一组相当严格的功能集）、项目是外包的、需求人员处于非常表面的层次、或者在日期出错时会产生严重的影响（经济或其他方面）等。
特性缓冲区和进度缓冲区是两类最常见的缓冲区。当团队确定了项目中所有需求的优先级，而且发现可能无法交付所有功能的时候，就需要建立一个特性缓冲区。另一方面，团队可以在进度表中包含一定量的时间来建立进度缓冲区，这个时间的量反映了蕴含在项目规模中的不确定性。团队可以通过同时估算每个用户故事具有50%的概率的大小和具有90%的概率的大小来构造进度缓冲区。通过对每队50%和90%估算值采用平方和和平方根的公式，可以估算出合适的进度缓冲区大小。
项目应该用特性缓冲区来预防特性不确定性，用进度缓冲区来预防进度不确定性。可以把特性缓冲区和进度缓冲区结合起来。实际上，这常常是个好方法，因为它可以让每个缓冲区的规模都更小。
计划多团队项目：
敏捷开发项目倾向于在开发大型项目时避免使用大型开发团队，而是使用多个团队。当有多个团队工作与一个项目时，他们就需要相互协调。
首先，团队应该为他们的估算建立一个共同的基准。所有战队都应该同意按照相同的单位进行估算：要么是故事的，要么是理想人天。
其次，当多个团队需要一起工作的时候，尽早给他们的用户故事增加细节常常很有帮助。进行这一工作的最佳办法是确认产品负责人对于用户故事的满意条件。满意条件就是一旦故事完全实现了，就可以进行演示的那些细节。
第三，在发布计划过程中结合一个滚动性前瞻计划，可以让多个团队受益。滚动性前瞻计划简单地向前看几次迭代（典型的是2～3次），通过共享在不久的将来每个团队分别会处理那些工作的信息，让团队之间可以协调工作。
第四，在具有很多团队间依赖性的高度复杂项目中，把馈送缓冲区结合到计划中是很有意义的。馈送缓冲区是一段时间，可以避免由于一个团队推迟交付而导致另一个团队推迟启动。
监督迭代计划：
任务板：常常是一张白板、软木板或者只是墙上特定的一片区域，可以帮助开发团队组织他们的工作，并把它们可视化。任务版的各列都带有标题，团队成员根据工作进展把任务卡在个列间移动。
迭代燃尽图：只是用来跟踪当前迭代中的工作，它的纵轴是剩余工作的小时数，而横轴是迭代中的天数。
团队不应该计算或跟踪个人速度。
