背景
在某开发团队辅导的第二天，一个团队负责人咨询道：“领导经常管我要开发计划，我如何能快速的评估出预计开发完成时间呢，我们目前用工时估算，我听说过故事点估算，不知道适合吗？”
问题分析
从这个团队负责人那里了解到，领导一般在接到项目大量新需求时会问这个问题。领导需要做到“心里有数”，有一个预计的项目新需求完成时间。加上领导一直做传统的瀑布开发项目，他非常关心项目中远期计划，也就是我们通常讲的里程碑或关键结点的问题。
团队目前使用敏捷开发方式初期，团队成员本身也对如何更快、更好地做好估算感到困惑，目前纠结是否应该采用故事点估算。
从以上问题分析中可以得出：第一，团队对故事点不了解，需要学习什么是故事点；第二，解决如何快速提供给领导开发计划的问题。
解决措施
解决问题我们来分两步走。首先解决不熟悉故事点的问题，先给大家介绍一下故事点的定义及特性。然后大家了解一下两层估算即产品待办列表估算和Sprint待办列表估算的简单区别，解决开发计划的问题。
如果有时间，建议可以先看看上篇《如何估算第二篇：利用核心概念理解估算》了解估算的核心概念。然后再来看这篇文章效果更好。这篇文章主要讲故事点。具体的估算方法有没有比较好的实践呢？在《如何估算第四篇：利用2种常见方法做估算》中会介绍几种比较好的估算方法，包括：“计划扑克估算”、“敏捷估算2.0（Agile Estimating 2.0）”等。本篇仍然在为估算做技能储备（磨刀不误砍柴功），即明确什么是故事点。前面文章已经讲过估算的一个核心概念即估算相对大小，这个相对大小我们用故事点为单位。工时和理想人天相信大家都理解，不做过多解释。在这里着重从故事点的定义、故事点的特性两个方面解释下什么是故事点，然后解决给领导提供计划的问题。
故事点的定义
故事点是表述一个用户故事，一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300，而要使用1、2、3。估算结果是相对值，而不是绝对值。
“当使用故事点来估算用户故事的大小时，并没有固定的公式来规定如何计算故事点的数值。故事点估算用于评估为了交付一个用户故事所包含的工作量（team effort），用户故事的复杂度(complexity)，风险，以及所有其他需要考虑的元素。——《Agile Estimating and Planning》, Mike Cohn.
故事点的特性说明
是相对单位
它是一个相对单位。比如，不同的组织团队，对于同样的用户故事的故事点大小一般是不同的；即使同一团队，针对不同用户故事的故事点大小，甚至是针对同一用户故事的故事点大小，都允许是不同的。但同时提醒，不同团队不同用户故事的故事点的设定，有利于组织能力的积累和横向参考。
不等同于工作量估算
故事点估算不是简单等同于工作量估算。如Mike Cohn所描述，它包含工作量、技术含量、各方面制约等多方面价值因素。有时其他的这些因素，在故事点估算中占有比重会胜过工作量方面的考虑。
考虑“完成的定义”
故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。
以上介绍，有些朋友可能会问：有些团队用工时（单位小时）来估算，不可以吗？上一篇文章末尾提到，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。
如果一定要推荐工时（或理想人天）和故事点分别在什么时候应用比较好，那么我一般推荐在做产品待办列表估算时用故事点，而Sprint待办列表估算时用工时（单位是小时）。
原因很简单，结合最开始团队负责人的问题，其实老板大多对什么时间点可以交付多少需求（用户故事形式体现）感兴趣。最常见的问题是：“这50个需求什么时间可以做完？”很明显，老板并不是在问本Sprint能做完多少需求，而是在问项目得有一个预计的时间点或里程碑。换句话说就是，需要对某个时间点可以交付什么样价值做出一个长期一点的预测。如果每个故事平均15分钟估算，那么50个用户故事估算需要50*15分钟=750分钟=12.5小时。显然估算所需要花费的时间代价比较高，ROI太低。如果采用准确度差不多的故事点估算，则效率会大大提升。前面提到过为什么故事点估算容易，这里不再重复解释。此时建议团队平均3分钟完成一个用户故事的估算，那么估算需要50*3分钟=150分钟=2.5小时。这样根据团队正常速率，就可以预计完成时间，回答老板的问题了。
对于Sprint列表的估算，其目标更多的是要确定团队本Sprint要完成的工作量，故事点显得有点抽象。团队具体执行时，时间概念上有点困难，而小时数就容易得多。通常Sprint列表项也会比产品待办列表项少得多，所以时间上不会花费太多。另外，就Sprint列表中的工作项而言，它会是更具体的需求，通常会进行任务细化和“完成定义”，进而很清楚如何去做，谁来做。这些因素综合看，以工时（小时）来估算成为优势。
参考附录
1. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。