在估算用户故事点数的时候，你有没有遇到跟我一样的疑问：

• 用户故事的工作量为什么要用故事点估算，而不是时间（比如人天）？
• 故事点估算为什么要用斐波那契数列？
• 斐波那契数列的数字为什么被改了？
• 为什么要用估算扑克？
• 为什么要有基准故事？
• 怎样确定基准故事？
• 其他故事怎样与基准故事做相对估算？
• ……

本文将为你一一解决上述问题。全文大概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个因素考虑：

1. 要开展的工作数量（The Amount of Work）
   如果要开展的工作越多，工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个只需要输入一小段文本的字段。
   第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。
   应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，由于规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的2或3或10倍。
2. 风险和不确定性（Risk and Uncertainty）
   产品待办项的风险和不确定性会影响其故事点估算值。
   如果产品待办项的干系人在询问需求时说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。
   如果要实现一项功能时需要改动一段缺乏自动化测试、结构脆弱的老代码，那么估算结果中也应该反映这个风险。
3. 复杂度（Complexity）
   在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。
   现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或社会安全号码；另一些字段则需要做信用卡号码的校验和验证。
   页面上的字段之间还需要相互交互。如果用户输入一个VISA卡，会显示三位CVV字段。但是如果用户输入美国运通卡，则需要显示四位CVV字段。
   尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。
   这种额外的复杂度都应该反映在所提供的估算结果中。

5.3. 使用规划扑克集体估点

规划扑克

在3.2节介绍了怎样使用“德尔菲法”降低从众效应的影响，在敏捷开发中，我们可以借助规划扑克来进行匿名投票。在估算会议上，团队中的每位人员都会得到一副纸质扑克，当然，随着移动互联网的普及，目前大多数敏捷团队使用了更为便捷的电子扑克。这里有2张扑克的含义需要解释下：

1. 如果有人出了“☕️”这个扑克，说明需要休息一会了；
2. 如果有人出了“？”这个扑克，说明他不了解需求，无法估算工作量，PO需要尝试重新澄清需求。

同3.2节介绍的案例一样，我们在规划故事点数时，第一轮大家的估点可能也会有很大的差距。如果估算值差距明显，代表大家对该用户故事的工作量、风险和不确定性、复杂度没有获得共识，估点高和估点低的人需要给他们一个机会阐述如此估点的理由。大家对该故事所包含的细节达成共识后，再对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。

如果对于同一个用户故事的评估中，可能评估的故事点数不完全一致，但点数之间差距不大，比如在3和5个故事点之间，该用户故事评估故事点数可以采用平均值法进行计算，将平均值结果与斐波那契数列比较，并把与评估故事点差值较小的故事点数作为用户故事的最终点数。

如在A故事的评估中，共有7人参与评估，其中4人评估的故事点数为3，3人评估的故事点数为5，则取平均值后的故事点数为3.85，与斐波那契数列中的3和5比较，平均值与故事点3差值更小，所以，该用户故事的最终点数为3，该用户故事点数评估完成。

5.4. 其他

关于故事点估算还有很多小细节，我大概列一下我的看法，就不详细展开了，各位看官如果有更好的做法，欢迎留言指教：

• 在哪一个会议上进行故事点估算？
  如果有梳理会，就在梳理会进行；如果没有的话就在计划会上进行。
• 估算完成后，可以任意亮牌吗？
  不可以，必须一起亮牌，并且在估算过程中，团队成员之间也不可以互相讨论预估的点数。
• PO和SM参与估算吗？
  不参与。只有开发团队参与估点，注意是开发团队，包括研发和测试人员。
• 超过多少点数用户故事需要重新拆分？
  每个团队的基准故事点规模不一样，所以没法给个确切数字，但是建议刚组建的敏捷团队最好不要超过5，后期可以根据团队的反馈进行调整。
• 实际开发中发现了估算失误要不要修改点数？
  不要。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费过多的时间精力，这是本末倒置。而且就我的经验来看，一个迭代中确实会有些故事被低估，但是也会有一些高估的故事，所以就迭代整体来看，故事点不会波动太多。
• 很小的需求，也必须要团队集体估算吗？
  要。估点是团队对需求理解对齐的过程。如果需求真的很小，估点的过程也会很快达成一致的，不会耽误大家多少时间。

参考资料

1. 《敏捷革命》，Jeff Sutherland，中信出版集团。
2. Why the fibonacci sequence works well for estimating，Mike Cohn。
3. The main benefit of story points，Mike Cohn。
4. What are story points，Mike Cohn。
5. 韦伯定律，百度百科。
6. 黄金比例分割，百度百科。
7. 斐波那契数列，百度百科。
8. 德尔菲法，百度百科。