传统上，项目经理往往会致力于创建很详细的估算，这个估算从财务的角度要经得起推敲。当然这样的估算是基于能够预见的情况再加上针对“已知的未知因素”所设的应急预算…… 然而就像Donald Rumsfeld的名言所说“有一些我们未知的未知因素——有些事情我们根本不知道我们不知道”。就像上面那些商人，我们永远无法预知那些意想不到的情况。我们花越长的时间来创建详细的估算，麻烦却越多。我们可以把详细的估算看作是一个绑定报价，一个不同于真正交付价值的目标，它使得我们的注意力都放到能在协议的日期和成本内交付一些东西——任何东西，无论它的价值高低。
在每次实施后的回顾评审中，初始估算和实际之间的差距总是让我们备受打击，然后告诉我们自己下次再努力些。爱因斯坦曾经说过，所谓神经错乱就是“一遍又一遍地做同样的事情，却期望得到不同的结果”。因此事情不应该这样，一定有其它更好的方法。
敏捷项目显然就不是这样?我们何不就从一个大概的需求范围开始，然后在做的过程中逐渐理清细节?嗯，对，但也不全对。在敏捷项目中我们不会去创建详细的估算来束缚自己，但是对将要进行的工作量的大小有一个认识还是很重要的，这就是为什么……
1、为什么我们需要估算?
忘掉那些传统的估算，那些漂亮的精心制作的甘特图，那些图表迫使我们的注意力都放在要进行的任务上，而不是要交付的成果。在项目中有三种活动需要我们进行一些粗略的估算。
当我们在考虑一个新提议项目的合理性时，我们需要提前知道大概的成本，这样才能决定是否值得投入。
当我们正在将新的或改进的产品推向市场时，我们需要知道那些重要的特性大概什么时候可以发布，这样我们才能安排相关的活动。
当我们在为工作排优先级时，产品负责人需要知道每个故事(或待办清单项)的成本，而团队需要知道每个故事的价值。
有件事很有意思，只要整个团队都一起参与进来共同协作，估算本身也可以变成一种很有意义的活动。它有助于团队增进理解，并保证团队每个人都对要交付的需求范围和价值达成共识。
然而对“估算”这个词的传统理解可能会让我们偏离这个方向。
2、使用“大小”而不是“估算”
为了避免让人误会我们讨论的是对成本和时间的估算，当我们评估一个故事的复杂程度时，有些人喜欢用“大小”而不是“估算”来描述。在90年代当我第一次使用Scrum和XP时——那时它们都还没有被称为敏捷实践——我们是使用T-shirt尺寸来评估故事的大小(S，M，L，和XL)。
现在我们使用故事点数——一种评估故事之间相对大小的方法——因此我们先找到可能最简单的故事，将它的点数设为1点，接下来用其他的故事与它进行比较，如果另一个故事比这个更复杂，那个故事可能就是3点。
让评估变得更有趣的是，我们不采用简单连续的数列，比如1，2，3，4，5等——而是采用一种近似菲波拉契数列的形式，像1，2，3，5，8，13等(就如《达芬奇密码》里面看到的)。这样当数字越大相邻数之间的间隔也越大，使得我们更容易区分哪个故事更小哪个更大。
尽管这不是一种精确的科学，但对上面提到的三种需要估算的情况这种方法已经足够好了。像John Maynard Keynes所说，“粗略的正确好过精确的错误”。这也意味着，我们仍然需要将故事点数转换成粗略的时间和成本估算。
另一个主要用于敏捷项目的实践是建立“完成标准”，就是对一个故事要能够标注为完成并可发布所需要满足的所有条件进行全面的理解，包括各种