项目，比如用户文档、翻译、广告等等。
假如我们有清晰的完成标准，就可以拿几个样例故事来计算所需要的工作量。基于这种计算我们就能为投资决策进行粗略的成本估算，为版本计划进行粗略的时间估算，让我们对故事有更充分的认识以便能协助产品负责人进行故事优先级的设置。
然而有些人仍然认为即使以故事的方式进行估算也会让我们从真正的价值交付上分心。针对这一点，有一个围绕着#NoEstimates的讨论。
3、什么是#NoEstimates讨论
如果你在Twitter上关注了任何一位敏捷方面有影响力的人，你可能已经注意到他们有些人参与了#NoEstimates 标签的讨论。看起来这是要我们完全停止进行估算，其实它是要我们不再进行故事点数的评估，而是立即开始开发。
这个讨论自从出现后已经有了一个迅速发展的势头，因为那些在大项目中工作的人他们感觉无论是用故事点数进行评估还是仅仅统计故事的个数，团队产量的跟踪结果基本是相同的。
#NoEstimates这种方式使得故事的优先级设置更简单了，使得交付团队能够更快地开始工作。然而可怜的产品负责人和项目投资方他们仍然需要知道项目大概要花费多少成本，需要多长时间。好消息是我们还可以基于故事个数的统计来进行粗略的估算，只要项目能够建立起足够有效的度量指标来让这样的估算可行。对于任何刚开始敏捷之旅的新团队来说，无论如何我都强烈建议你们采用故事点数进行估算，直到你具有了和那些团队一样的丰富经验和成熟度。
一定程度上这可能是因为那些有经验的交付团队每个迭代会将故事实时地(Just-in-time)以一致的标准拆分成更小的故事——这样的拆分使得团队每个迭代能产出更多潜在可交付的增量——无论项目在迭代里是采用的非常小的故事，还是适度大一些的故事，最终每个迭代的产能报告看上去都差不多。