在估算用户故事点数的时候，你有没有遇到跟我一样的疑问：
- 用户故事的工作量为什么要用故事点估算，而不是时间（比如人天）？
- 故事点估算为什么要用斐波那契数列？
- 斐波那契数列的数字为什么被改了？
- 为什么要用估算扑克？
- 为什么要有基准故事？
- 怎样确定基准故事？
- 其他故事怎样与基准故事做相对估算？
- ……
本文将为你一一解决上述问题。全文大概5000字，预计阅读时间15分钟，如果你也有类似困惑，可以花点时间阅读下，相信不会让你失望的。
1. 为什么使用故事点而不是时间
在回答这个问题之前，先看个例子：
韩梅梅喜欢跑步，但是她跑得很慢，而李雷却跑得很快。李雷指着北京奥林匹克森林公园对韩梅梅说：我们跑南园这条路吧，这大概要花30分钟。
这条路韩梅梅很熟，但是作为一个跑步很慢的人，韩梅梅心里清楚这要花60分钟。所以，韩梅梅告诉李雷，她跑过这条路的，需要花60分钟。
然后他们就争执起来了：30-60-30-60……
他们争执半天没有结果。也许他们可以妥协一下，需要45分钟？但是这也许是最坏的结果，因为他们虽然有了一个折中结果，但是，这个结果对大家都没不太实际：李雷觉得太慢了，而韩梅梅觉得太快了。
所以，他们继续争论：30-60-30-60……
最终，李雷跟韩梅梅说：这段路大概5公里，我能在30分钟内跑完它。
韩梅梅说：我同意这段路程是5公里，但它要花我60分钟。
他们两个都是对的：李雷真的能在30分钟内跑完，韩梅梅也真的需要60分钟。但当他们想为这段路程统一时间估算时，他们发现做不到，因为大家工作（跑步）的速率不同。
但是，当他们使用了一个抽象的度量单位（公里），他们就达成了一致。李雷和韩梅梅都同意这段路程是5公里，他们仅仅在要花费多长时间上意见不同。
例子说完了，相信大家已经对时间和公里（抽象度量单位）有了一点理解。
敏捷开发中的“故事点”跟例子中的“公里”作用差不多：它能使不同技术水平和工作速度的人在估算结果上保持一致。当然，敏捷开发中的主角是具有不同产出效率的程序员，而不是例子中跑得快的人和跑得慢的人。
就像这两个跑步的人，两个程序员也许同意一个用户故事是5个故事点（类比例子中的5公里，都是一种抽象度量单位）。资深程序员可能觉得这很容易，1天（时间）就能完成。初级程序员可能觉得需要2天才能搞定。但是他们能在5个故事点上达成一致，因为把第一个用户故事定成5个故事点是不需要什么依据的。
不过，最重要的是，一旦他们同意第一个故事是5个点，这两个程序员就可以对后续估算达成共识。如果资深程序员认为一个新的用户故事将需要两天（两倍于他估计为5个点的故事），他将评估新的故事为10个点。而初级程序员也会这样做，当他需要4个工作日（两倍于他估计为5个点的故事），他将评估新的故事为10个点。
所以，使用故事点而不使用时间的原因是，故事点可以使能力不同的程序员在估算同一任务时快速达成一致。
2. 为什么要使用斐波那契数列估算故事点
2.1. 人们只能识别一定百分比外的差异
德国生理学家E.H.韦伯通过对重量差别感觉的研究发现一条定律，即感觉的差别阈限随原来刺激量的变化而变化，而且表现为一定的规律性，刺激的增量(△I)和原来刺激值(I)的比是一个常数(K)，用公式表达即K=△I/I，这个常数叫韦伯常数、韦伯分数或韦伯比率。
上面的定义是从百度百科拷贝下来的，简单来说就是：我们只能识别出两个物体间一定百分比外的差异。
比如：一公斤和两公斤之间的差别是100％，但是20公斤和21公斤之间的差异仅为5％。所以您可能可以区分1公斤和2公斤的物品，但您可能无法分辨出20公斤和21公斤的物品，因为20公斤和21公斤两者之间的百分比差异太小了。
这就是韦伯定律想要告诉我们的：差异太小，我们是识别不到的；只有差异大到一定程度，才能被我们识别。
2.2. 人们可以识别到多大差异的区别
韦伯定律只是告诉了我们可以识别一定百分比差异外的区别，但是这个百分比是多少呢？
自然界有个神奇的数字：0.618，即黄金分割比例。
黄金分割比例的现象在我们身边有很多，比如：
- 人们的肚脐是人体总长的黄金分割点
- 大多数门窗的宽长之比也是0.618
- 有些植茎上，两张相邻叶柄的夹角是137°28'，这恰好是把圆周分成1:0.618
- 一些名画、雕塑、摄影作品的主题，大多在画面的0.618处
- ……
甚至在医学领域，当一个患者报告说自己感受到了病情的好转，那么实际上他的病已经好了65%。
也就是说，61.8%这个百分比差异对很多人来说，是可以轻易分辨出来的。
2.3. 为什么使用斐波那契数列估算故事点
斐波那契数列之所以能很好的用于故事点的估算，是因为它们大致符合了黄金分割点。在这个数列中，1、2、3、5、8、13、21……，前两个值之后（后一个值比前一个值大100％），后面的每个数字都比前一个数字值大60％左右。
根据韦伯定律，如果我们可以区分两个工作量相差60％的故事，则可以区分其他相同百分比差异的故事。
因此，斐波那契值之所以能很好地工作，是因为它们每次都以大约相同的比例增加，且该比例基本符合黄金分割比例。
3. 如何降低Scrum团队中的从众效应
3.1. 什么是从众效应
在估算故事点时，当有人提出一个估算，即使你不同意，但当别人都表达赞同时，你还是会随声附和，这就是所谓的“从众效应”：人们认为如果其他人都赞同某一件事时，那么自己的保留意见则是愚蠢的或是误导性的，他们不想在其他人面前出丑。
这个弱点不是个体独有的，而是全人类共有的。
与“从众效应”相关的概念还有信息瀑布和光环效应：
- 信息瀑布
一篇叫做《A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades》的论文中首先提到了这个概念：如果一个人观察到之前众人的行为后，认为最佳的做法是放弃自己掌握的信息，遵从之前众人的行为，那么这个时候信息瀑布就出现了。 - 光环效应
当认知者对一个人的某种特征形成好或坏的印象后，还倾向于推论该人其他方面的特征，本质上属于以偏概全的认知错误。与从众效应一样，光环效应也会导致人们将目光集中到某一个有正面色彩的光环上，从而忽视了实际数据。
3.2. 使用“德尔菲法”降低从众效应的影响
德尔菲法，也称专家调查法，1946 年由美国兰德公司创始实行，其本质上是一种反馈匿名函询法，其大致流程是在对所要预测的问题征得专家的意见之后，进行整理、归纳、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直至得到一致的意见。
兰德公司使用这个方法做过一个匿名投票，投票的主题是“冷战期间，如果苏联要摧毁美国的主要工业目标，需要多少枚原子弹？”。
他们找来了一群专家，包括4名经济学家、1名物理脆弱性方面的专家、1名系统分析师及1名电气工程师。这几个人都是各个领域的专家，但是第一轮投票的结果差别非常大，少则50枚，多则5000枚。
在第一轮投票后，组织方将各个专家的意见整合后发给了大家，比如各个目标的脆弱性、各个行业的恢复能力、工厂的安全性、不同零部件的交付周期、打击目标的准确性等等，然后又组织各位专家进行了第二次投票，评估差异缩小到了89~800之间。
反复开展上述过程，最终差异越来越小，最后落在了167~360之间。
最初的评估结果相差100倍，到最后，缩小到了2倍。借助这一工具，既能让专家达成普遍的共识，又不会担心出现什么偏见。
敏捷开发中也是使用该方法对用户故事进行估点的，具体方法会在第5章中介绍。
4. 为什么敏捷估算要使用修正后的斐波那契数列
标准的斐波那契数列是1、2、3、5、8、13、21、34、55……，但是目前绝大多数团队敏捷估算时使用的斐波那契数列是1、2、3、5、8、13、20、40、100……，数列的前面6个数字是一样的，但是从第7个数字开始，就完全不一样了，这是为什么呢？
Mike Cohn在他的Why the fibonacci sequence works well for estimating一文中提到，早期他都是根据真实的斐波那契数列进行的估算（1、2、3、5、8、13、21、34、55……）。
这个数列越往后数字越大，也就说明估算越不准确，所以对于21、34、55这样的估算值，很多人都觉得很奇怪：既然已经估不准了，为什么非要使用21，而不将其四舍五入为20或25呢？
于是Mike Cohn就接受了这个建议，他在之后的团队辅导及授课中就都开始使用20而不是21了，并且一直持续到了现在。
后来他又尝试使用了40和100这两个数代替了数列的其他值，之所以这么使用，是因为任务的粒度越粗，估算就越不准确，也就越不需要纠结到底是80、90还是100了。
同时，使用40和100也是不违反韦伯定律的，它们分别比之前的数字增加了100％（20 →40）和150％（40 →100）。这比黄金分割比例的61.8％大得多，人们是可以轻松的分辨出这些工作量的区别的。
于是在Mike Cohn的影响下，现在大部分公司在敏捷估算中都是使用的修正后的斐波那契数列：1、2、3、5、8、13、20、40、100、∞。
5. 如何估算故事点
5.1. 确定基准故事点
每次估算时，最好使用相同的标准用户故事作为1个点，这样对于整个项目的统计有很大帮助。使用相对值进行估算，可以有效的统计团队的生产能力在各个迭代的变化。
对于初次实施敏捷的团队，对故事点的评估可能还是不太容易理解，根据我的实践经验，初次评估故事点时，可以尝试使用1人天的工作量作为一个故事点。如果团队成员的水平参差不齐的话，那就建议用其中一个中等水平的研发作参考，使用他的1人天的研发产出作为1故事点的参考。
5.2. 相对估算的依据
基准故事点确定好以后，其他的故事怎样与它对比呢？怎样确定另一个故事的工作量是基准故事的几倍呢？我们可以从以下3个因素考虑：
- 要开展的工作数量（The Amount of Work）
如果要开展的工作越多，工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个只需要输入一小段文本的字段。
第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。
应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，由于规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的2或3或10倍。 - 风险和不确定性（Risk and Uncertainty）
产品待办项的风险和不确定性会影响其故事点估算值。
如果产品待办项的干系人在询问需求时说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。
如果要实现一项功能时需要改动一段缺乏自动化测试、结构脆弱的老代码，那么估算结果中也应该反映这个风险。 - 复杂度（Complexity）
在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。
现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或社会安全号码；另一些字段则需要做信用卡号码的校验和验证。
页面上的字段之间还需要相互交互。如果用户输入一个VISA卡，会显示三位CVV字段。但是如果用户输入美国运通卡，则需要显示四位CVV字段。
尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。
这种额外的复杂度都应该反映在所提供的估算结果中。
5.3. 使用规划扑克集体估点
在3.2节介绍了怎样使用“德尔菲法”降低从众效应的影响，在敏捷开发中，我们可以借助规划扑克来进行匿名投票。在估算会议上，团队中的每位人员都会得到一副纸质扑克，当然，随着移动互联网的普及，目前大多数敏捷团队使用了更为便捷的电子扑克。这里有2张扑克的含义需要解释下：
- 如果有人出了“☕️”这个扑克，说明需要休息一会了；
- 如果有人出了“？”这个扑克，说明他不了解需求，无法估算工作量，PO需要尝试重新澄清需求。
同3.2节介绍的案例一样，我们在规划故事点数时，第一轮大家的估点可能也会有很大的差距。如果估算值差距明显，代表大家对该用户故事的工作量、风险和不确定性、复杂度没有获得共识，估点高和估点低的人需要给他们一个机会阐述如此估点的理由。大家对该故事所包含的细节达成共识后，再对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。
如果对于同一个用户故事的评估中，可能评估的故事点数不完全一致，但点数之间差距不大，比如在3和5个故事点之间，该用户故事评估故事点数可以采用平均值法进行计算，将平均值结果与斐波那契数列比较，并把与评估故事点差值较小的故事点数作为用户故事的最终点数。
如在A故事的评估中，共有7人参与评估，其中4人评估的故事点数为3，3人评估的故事点数为5，则取平均值后的故事点数为3.85，与斐波那契数列中的3和5比较，平均值与故事点3差值更小，所以，该用户故事的最终点数为3，该用户故事点数评估完成。
5.4. 其他
关于故事点估算还有很多小细节，我大概列一下我的看法，就不详细展开了，各位看官如果有更好的做法，欢迎留言指教：
- 在哪一个会议上进行故事点估算？
如果有梳理会，就在梳理会进行；如果没有的话就在计划会上进行。 - 估算完成后，可以任意亮牌吗？
不可以，必须一起亮牌，并且在估算过程中，团队成员之间也不可以互相讨论预估的点数。 - PO和SM参与估算吗？
不参与。只有开发团队参与估点，注意是开发团队，包括研发和测试人员。 - 超过多少点数用户故事需要重新拆分？
每个团队的基准故事点规模不一样，所以没法给个确切数字，但是建议刚组建的敏捷团队最好不要超过5，后期可以根据团队的反馈进行调整。 - 实际开发中发现了估算失误要不要修改点数？
不要。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费过多的时间精力，这是本末倒置。而且就我的经验来看，一个迭代中确实会有些故事被低估，但是也会有一些高估的故事，所以就迭代整体来看，故事点不会波动太多。 - 很小的需求，也必须要团队集体估算吗？
要。估点是团队对需求理解对齐的过程。如果需求真的很小，估点的过程也会很快达成一致的，不会耽误大家多少时间。
参考资料
- 《敏捷革命》，Jeff Sutherland，中信出版集团。
- Why the fibonacci sequence works well for estimating，Mike Cohn。
- The main benefit of story points，Mike Cohn。
- What are story points，Mike Cohn。
- 韦伯定律，百度百科。
- 黄金比例分割，百度百科。
- 斐波那契数列，百度百科。
- 德尔菲法，百度百科。