深度解析：故事点估算看这一篇就够了 | IDCF

我在辅导团队对用户故事进行故事点估算的时候，经常会遇到如下问题：

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

我在翻阅了大量零散的资料以后，终于把这些问题搞清楚了。如果你也遇到过类似上述的问题，可以花点时间阅读下这篇文章，相信不会让你失望的。

一、为什么用故事点而不是时间

在回答这个问题之前，我们先看个例子：

韩梅梅和李雷一起去北京奥林匹克森林公园跑步，李雷对韩梅梅说：我们跑南园这条路吧，这大概要花30分钟。

这条路韩梅梅很熟，但是作为一个跑步很慢的人，韩梅梅心里清楚这要花60分钟。所以，韩梅梅告诉李雷，她跑过这条路的，需要花60分钟。

然后他们就争执起来了：30-60-30-60……

他们争执半天没有结果，作为一个热心的旁观者，你可能会劝他们互相妥协一下，就算45分钟吧？但是这样也许是最坏的结果，因为他们虽然有了一个折中的方案，但是这个结果对双方都不太实际：李雷觉得太慢了，而韩梅梅觉得太快了。

所以，他们继续争论：30-60-30-60……

最终，李雷跟韩梅梅说：南园这条路大概5km，我能在30分钟内跑完它。

韩梅梅说：我同意这段路程是5km，但它要花我60分钟。

他们两个都是对的：李雷真的能在30分钟内跑完，韩梅梅也真的需要60分钟。但当他们想为这段路程统一时间估算时，他们发现做不到，因为大家跑步的速率不同。

但是，当他们使用了一个抽象的长度度量单位（km），他们很快就达成了一致。李雷和韩梅梅都同意这段路程是5公里，但是由于他们的速度（相对度量单位）不同，导致他们花费的时间（绝对度量单位）也不同。

例子说完了，很多人这时候可能已经想到了一个公式：距离（km）=速度（km/h）*时间（h），那我为什么要举这个例子呢？难道只是带大家回忆一下小学数学？

其实软件开发中任务的工作量跟跑步的“距离”是非常类似的概念：同一个任务，不管谁来做，它的工作量都是一样的，只不过能力强的人就做得快一点（耗时少）；能力弱的人就做得慢一点（耗时多）。

与跑步类似，如果我们让多个人就同一个开发任务的耗时达成一致，那是很难的，但是如果我们能有一个描述软件开发工作量的单位（类似表示举例的km），我们可能就能很快达成一致。而“故事点”就是敏捷开发创造出来的用来表示开发任务工作量的单位，它跟例子中用来表示距离单位的“km”的作用差不多：它能使不同技术水平和工作速率的人在工作量的估算上快速达成一致。当然，敏捷开发的主角是具有不同工作效率的开发人员，而不是例子中不同跑步速度的跑者。

就像这两个跑步的人，两个程序员也许同意一个用户故事是5个故事点（类比例子中的5公里，都是一种抽象度量单位）。高级开发人员可能觉得这很容易，1天（时间）就能完成。初级开发人员可能觉得需要2天才能搞定。但是他们能在5个故事点上快速达成一致，因为把第一个用户故事定成5个故事点是不需要什么依据的（就像不同国家或地区对长度单位的定义可能不同，比如米、寸、英寸等，每个团队对故事点的大小也都可以有自己的标准，只要团队成员都认可即可）。

不过，最重要的是，一旦他们同意第一个故事的工作量是5个点，这两个开发人员就可以对后续估算达成共识。如果高级开发人员认为一个新的用户故事将需要两天（两倍于他估计为5个点的故事），他将评估新的故事为10个点。而初级开发人员也会这样做，当他估算需要4个工作日时（两倍于他估计为5个点的故事），他将评估新的故事为10个点。

所以，使用故事点而不使用时间的原因是，故事点可以使能力不同的开发人员在估算同一任务时快速达成一致。

二、为什么要用斐波那契数列估算故事点

2.1 人们无法分辨太小的差异

德国生理学家E.H.韦伯通过对重量差别感觉的研究发现一条定律，即感觉的差别阈限随原来刺激量的变化而变化，而且表现为一定的规律性，刺激的增量(△I)和原来刺激值(I)的比是一个常数(K)，用公式表达即K=△I/I，这个常数叫韦伯常数、韦伯分数或韦伯比率。

上面的定义是从百度百科拷贝下来的，简单来说就是：我们只能分辨出两个物体间一定百分比外的差异。

比如：我们大部分人都能分辨出1公斤和2公斤物体，但可能无法分辨出20公斤和21公斤物品。它们同样是相差了1公斤，为什么有的能分辨出来，有的就分辨不出来了呢？这是因为1公斤和2公斤之间的差别是100％，但是20公斤和21公斤之间的差异仅为5％，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％的故事，则可以区分其他相同百分比差异的故事。

因此，斐波那契值之所以能很好地工作，是因为它们每次都以大约相同的比例增加，且该比例基本符合黄金分割比例。

三、为什么敏捷估算要使用修正后的斐波那契数列

标准的斐波那契数列是1、2、3、5、8、13、21、34、55……，但是目前绝大多数团队在估算时使用的斐波那契数列是1、2、3、5、8、13、20、40、100……，数列的前面6个数字是一样的，但是从第7个数字开始，就完全不一样了，这是为什么呢？

Mike Cohn曾经在他的文章中提到，早期的估算他都是根据真实的斐波那契数列进行的（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、∞。

四、为什么要使用规划扑克

相信很多人在估算故事点时，都是使用物理或电子的规划扑克进行的，我们为什么要这么做呢？这个问题需要从一个心理学名词“从众效应”说起。

4.1 什么是从众效应

在估算故事点时，当有人提出一个估算，即使你不同意，但当别人都表达赞同时，你还是会随声附和，这就是所谓的“从众效应”：人们认为如果其他人都赞同某一件事时，那么自己的保留意见则是愚蠢的或是误导性的，他们不想在其他人面前出丑。

这个弱点不是个体独有的，而是全人类共有的。

与“从众效应”相关的概念还有信息瀑布和光环效应：

1）信息瀑布

一篇叫做《A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades》的论文中首先提到了这个概念：如果一个人观察到之前众人的行为后，认为最佳的做法是放弃自己掌握的信息，遵从之前众人的行为，那么这个时候信息瀑布就出现了。

2）光环效应

当认知者对一个人的某种特征形成好或坏的印象后，还倾向于推论该人其他方面的特征，本质上属于以偏概全的认知错误。与从众效应一样，光环效应也会导致人们将目光集中到某一个有正面色彩的光环上，从而忽视了实际数据。

从众效应的危害很大，我们要怎么做才能避免它呢？

4.2 使用“德尔菲法”降低从众效应的影响

德尔菲法，也称专家调查法，1946 年由美国兰德公司创始实行，其本质上是一种反馈匿名函询法，其大致流程是在对所要预测的问题征得专家的意见之后，进行整理、归纳、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直至得到一致的意见。

兰德公司使用这个方法做过一个匿名投票，投票的主题是“冷战期间，如果苏联要摧毁美国的主要工业目标，需要多少枚原子弹？”。

他们找来了一群专家，包括4名经济学家、1名物理脆弱性方面的专家、1名系统分析师及1名电气工程师。这几个人都是各个领域的专家，但是第一轮投票的结果差别非常大，少则50枚，多则5000枚。

在第一轮投票后，组织方将各个专家的意见整合后发给了大家，比如各个目标的脆弱性、各个行业的恢复能力、工厂的安全性、不同零部件的交付周期、打击目标的准确性等等，然后又组织各位专家进行了第二次投票，评估差异缩小到了89~800之间。

反复开展上述过程，最终差异越来越小，最后落在了167~360之间。

最初的评估结果相差100倍，到最后，缩小到了2倍。借助这一工具，既能让专家达成普遍的共识，又不会担心出现什么偏见。

为了降低用户故事估算时的“从众效应”，所以现在很多团队就采用了规划扑克这种独立投票的方式。规划扑克的具体使用方法会在第5.3节中进行介绍。

五、如何估算故事点

5.1 确定基准故事点

每次估算时，最好使用相同的基准用户故事作为1个点（称作基准故事点，类似表示距离时先确定好1km代表多长），这样对于整个项目的统计有很大帮助。其他的故事都基于这个基准故事做相对估算，就可以得到其他故事的工作量了，每个迭代完成的故事点可以有效的统计团队生产能力在各个迭代的变化。

对于初次实施敏捷的团队，对基准故事和基准故事点的确定可能会很迷茫：基准故事点如果定的太大，可能就会存在很多低于1故事点的故事；定的太小了又会导致其他故事的故事点会很大。根据我的实践经验，初次评估故事点时，可以尝试使用一个有1次前后端网络通信、前端有一个页面、后端有一次数据库交互的用户故事作为基准故事，将其工作量定位1个故事点，比如很多系统都有的登录功能，就是一个很好的基准故事，这样的故事工作量不会太大，同时也不至于太简单。

5.2 相对估算的依据

基准故事点确定好以后，其他的故事怎样与它对比呢？怎样确定另一个故事的工作量是基准故事的几倍呢？我们可以从以下3个因素考虑：

1）要开展的工作数量（The Amount of Work）

如果要开展的工作越多，工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个要输入一小段文本的字段。

第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。

应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，由于规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的2或3倍。

2）风险和不确定性（Risk and Uncertainty）

用户故事的风险和不确定性会影响其故事点估算值。

如果用户故事的干系人在询问需求时说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。

如果要实现一项功能时需要改动一段缺乏自动化测试、结构脆弱的老代码，那么估算结果中也应该反映这个风险。

3）复杂度（Complexity）

在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。

现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或身份证号；另一些字段则需要做银行卡号的校验和验证。

页面上的字段之间还要相互交互。如果用户输入的是一个189开头的号码，则运营商字段默认显示中国电信。但是如果用户输入的是一个139开头的号码，则运营商字段默认显示中国移动。

尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。

这种额外的复杂度都应该反映在所提供的估算结果中。

5.3 使用规划扑克集体估点

(规划扑克)

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

如果有人出了“☕️”这个扑克，说明需要休息一会了；

如果有人出了“？”这个扑克，说明他不了解需求，无法估算工作量，PO需要尝试重新澄清需求。

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

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

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

5.4 其他

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

1）在哪一个会议上进行故事点估算？

如果需求梳理会出席的人数较多（达到团队人数的2/3以上），就在梳理会上进行；如果人数较少的话就在计划会前单独召开一个简短的估算会议进行估点。不建议在计划会上估点。

2）估算完成后，可以任意亮牌吗？

不可以，必须一起亮牌，并且在估算过程中，团队成员之间也不可以互相讨论估算的点数。

3）PO和SM参与估算吗？

不参与。只有开发团队参与估点。注意是“开发团队”，它包括了开发和测试人员，而不仅仅是开发人员。

4）超过多少点数的用户故事需要重新拆分？

每个团队的基准故事点规模不一样，所以没法给个确切数字，但是建议刚组建的敏捷团队最好不要超过5，后期可以根据团队的反馈进行调整。

5）实际开发中发现了估算失误要不要修改点数？

不要。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费过多的时间精力，这是本末倒置。而且就我的经验来看，一个迭代中确实会有一些故事的点数被低估，但是也会有一些被高估的故事，所以就迭代整体来看，故事点不会波动太大。

6）很小的需求，也必须要团队集体估算吗？

要。估点是团队对需求理解对齐的过程。如果需求真的很小，估点的过程也会很快达成一致的，不会耽误大家多少时间。

7）规模化敏捷中的各个团队如何统一估算基线？

首先从各个团队召集一些骨干成员（每个团队最好能有2-3名），组成一个跨职能的估算团队；然后从整个产品待办列表中随机选择10-20个故事进行基准故事点的定义和估算工作，估算的过程中如果有人对相关的技术或需求不清晰，可以放弃；最后，参与估算的人，将这10-20个估点后的故事带回自己的团队，并将基准故事和其他故事的估点同步给团队，以此对齐大家对工作量的认识。

参考资料

• 《敏捷革命》，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。
• 韦伯定律，百度百科。
• 黄金比例分割，百度百科。
• 斐波那契数列，百度百科。
• 德尔菲法，百度百科。
• How to Estimate Story Points With Multiple Teams，Mike Cohn。

来源：小船哥说敏捷

作者：小船哥

4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址

• 0401《数据库持续交付流水线分享与演示（Azure DevOps+Flyway）》
• 0408《持续交付中的版本管理与基于Azure DevOps扩展框架的插件开发》
• 时间待定《微服务，多团队协作中的API测试怎么做 - Pact契约测试》
• 0422《BoatHouse端到端流水线展示》