共计 2243 个字符，预计需要花费 6 分钟才能阅读完成。
背景
在某开发团队辅导的第二天，一个团队负责人征询道：“领导常常管我要开发计划，我如何能疾速的评估出预计开发实现工夫呢，咱们目前用工时估算，我据说过故事点估算，不晓得适宜吗？”
问题剖析
从这个团队负责人那里理解到，领导个别在接到我的项目大量新需要时会问这个问题。领导须要做到“心里有数”，有一个预计的我的项目新需要实现工夫。加上领导始终做传统的瀑布开发我的项目，他十分关怀我的项目中远期打算，也就是咱们通常讲的里程碑或要害结点的问题。
团队目前应用麻利开发方式初期，团队成员自身也对如何更快、更好地做好估算感到困惑，目前纠结是否应该采纳故事点估算。
从以上问题剖析中能够得出：第一，团队对故事点不理解，须要学习什么是故事点；第二，解决如何疾速提供给领导开发计划的问题。
解决措施
解决问题咱们来分两步走。首先解决不相熟故事点的问题，先给大家介绍一下故事点的定义及个性。而后大家理解一下两层估算即产品待办列表估算和 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]. 北京：人民邮电出版社。
点击关注，第一工夫理解华为云陈腐技术~
