用户故事估算技巧

英文原文：

（作者：Jay Fields，译者：郑柯）

2008年8月15日

用2的幂进行估算

开始的时候，我会将故事的规模估算为1点、2点、3点、4点，或是小、中、大、特大。人们总是觉得：中等大小的故事，其工作量是小型故事的两倍；而大型故事是中等大小故事的两倍（诸如此类）。但到后来，发现这样的想法总是很难跟实际规划吻合起来。后来有人推荐我使用2的幂来估算。这一下，业务人员就能理解我们的表达方式了。他们会知道8点的故事要远超过1点的故事。我认为1点、2点、4点、8点这样的规模估算要更加合适。故事越大，其中包含的未知因素和风险也就越多。用2的幂进行估算，可以让人们对于大型故事所关联的风险更加注意。

使用4个数值

我参与过一个项目，他们用1、2、4、8作为估算值。前两次估算会议结束后，不到5%的故事只有1点，大约30%的故事是2点。项目经理决定去掉 1 这个估算值，因为他觉得这样做太容易了。此后的每次估算会议中，有趣的事情发生了：突然只有5%的故事变成了2点，相当多的故事变成了4点。开发人员改变他们的估算规模，我认为这不是有意的，只是开发人员总是会想得多一些。没几个开发人员愿意确定表明：用户故事非常简单，估算允许的最小数值就是它的工作量。在多次项目过程中见过类似行为后，我选择估算的最小数值为4点。不过我觉得用4点作为最大估算数值也不错。无论如何，这只不过就是估算而已。如果放太多精力在估算的准确度上，到后来就得负责说明为什么没能按照估算完成任务。估算的目的是要对项目规模和工作量有一个大致的概念，而不是要得到一个需要严格遵循的工作计划。

不能取平均数，不能使用不在估算取值范围中的数字

使用数字4，可以让你得到一个粗略的估算，而不必在精确程度上花费太多时间。有的故事感觉比2点大一点，但是又比4点小一点。这样的故事不能估算为3点。也没有理由使用3点进行估算。类似的故事隐含的风险或是未知因素让人觉得它不是2点，因此，它很有可能是一个4点的故事。如果使用平均数、或是不在估算取值范围中的数字，有可能给团队成员或是项目干系人造成暂时的（也是不必要的）困惑。同时，从项目整体的角度来看，偶尔不太确定的估算也不会影响大局。要保持简单，坚持使用取值范围中的数字。

独立投票

受他人影响是人的本性。如果一个技术leader说一个故事大小是两点，很可能其他团队成员都会随声附和。因此，在我负责的估算过程中，我会让每个团队成员独立做出自己的选择。要想达到这样的目的，可以为每个成员发一张纸，让他们在上面写上自己的估算，等到每个人都写好之后，大家可以一起展示各自的估算。另外一种方式，也是我喜欢的方式，是用 石头 剪子 布 （译注：英文名rock paper scissors，简称RPS）进行估算。在估算会议上，我们会一直讨论某个故事，直到大家都准备好估算为止，然后我们会一起 抛出 自己的估算，就像是同时伸手出石头、剪子、布一样。我所说的 抛出估算 就是：伸出一个手指头表示1点，两个手指头表示2点，四个手指头就是4点。要是表示8点，那就得双手并用了。

选取最大的估算值

即使反复提醒过了，开发人员们还是很难估算，因为他们仍会受到团队的影响。如果某个开发人员认为可以在一天内做完某个故事，他会伸出一个手指头。然而，这个故事也许不由该开发人员负责，另外的团队成员会接手，可是他可能会认为这个故事应该是2点甚至是4点。我总是选择团队成员给出的最大估算数值。也许有人认为这是小题大做，可实际上每个团队成员对于风险的认知不同，也许给出最大估算的成员想到的风险要比其他人更完备。选择最大的估算值还有其他好处。如果必须要同意一个较低的估算，那么做出最大估算的团队成员就得说明原因。对于团队中不那么资深的成员来说，这样的讨论可能让他觉得窘迫。对开发语言和工具相关经验的匮乏，他们可能不知道怎么样快速完成某项工作。他们的担心是由自己的技能水平决定的。如果因为不想讨论为什么估算值那么高而不愿意给出自己真正的估算，这对团队可无甚裨益。

对于取值高低的讨论，有可能使得整个团队提升估算值，或是让开发人员不甚情愿地降低自己的估值。不管怎样，你都要花更多时间来讨论，而这些讨论可能一无所获。到最后，最重要的还是保持一致。通过跟踪团队开发速度（注），团队在一个迭代中可以完成多少故事，这总是可以知道的。因此，即使估算有所 膨胀 ，速度也会随之变化，对于规划来说没有影响。

最后，选取最大的估算值可以节省估算会议的时间。如果团队中有人认为一个故事应该是8点，在讨论这个故事时，他可以大声说出来，宣称自己将抛出8点这个估算值。除非有人认为在团队成员的估算之间有很大差距，既然这个故事必将成为8点，那就没有必要再针对它讨论下去了

讨论大估算差

对于估算，经常会有误解，以为整个团队都同意某个故事的大小。如前所述，我会选择更大的指来解决估算不一致的问题。然而，有时很大的估算差距意味着存在某些误解。因此，如果有两个估算的值差距大于2，总是会引发讨论（比如，如果一个成员抛出1点，而另一个认为是4点，大家就得澄清一下了）。讨论这些大的差距，还可以减少给出最大估算的人被轻视的机会。

提防信息不足

有时会发生估算会议结束时还有故事未被估算的状况。与其匆忙给出一个让人不舒服的估算，不如去征询更多信息。估算为8点，暗示着这是一个很大的故事，但也意味着你觉得它会占用两倍于4点故事所用的时间。因此，不要随便将不清楚的故事估算成8点。估算会议的目标不是要得到所有故事的估算值，而是要为提供了足够信息的故事给出估算。

必要的投入

没人喜欢参加估算会议（好吧，就我所知的都不喜欢）。在我经历过的项目中，语速快的人负责将故事大声念出来，开发人员会问领域专家各种问题，然后他们会进行估算。当没人向领域专家发问时，他们会在自己的笔记本上做其他的事情。一开始，我觉得这是利用时间的好方法，但是他们却会因此而错过一些东西。后来我参加了这样一个项目，经理要求每个人轮流念一个故事。这样领域专家就参与进来了，因为他们害怕轮到自己念时看起来很愚蠢。由于每个人的全情投入，整个会议也变得更有价值了。

猪和鸡

在供应火腿和鸡蛋的餐馆里面，猪是全身心投入，而鸡只是参与而已。

我经常听到这样的话：业务人员不应该干扰开发人员的估算，因为开发人员属于 猪 的角色，而业务人员都是 鸡 。我真觉得这个类比很不好。一个坏的产品出来，更有可能被解雇的是业务团队，而不是技术团队。然而，让业务人员干扰估算是会引发利益冲突的。

这个问题也很容易解决。业务人员想知道他们在下个迭代后能得到哪些功能，他们需要估算。由于业务人员不写代码，他们的估算都不大准确。在实际的估算过程中，业务人员参与得越多，由此而对开发人员产生影响，也就有可能使业务人员得到的估算越不准确。在会议上，最好的领域专家只回答问题，而不会去干扰故事开发过程的一丝一毫。

估算小组人数

团队的大小各有不同。在小于等于6个人的小型团队中，我建议整个团队都参与估算会议。不同的观点有助于夯实项目远景，并对估算产生正面效果。不过，我相信是存在收益递减效应的。如果是大团队，就不一定全都参与针对每个故事的估算了。再说，这就是一个估算，6个人跟15个人的准确性不会有太大差别。如果你的团队多于6个人，我建议分成不同的估算小组。一般来说，我希望最少能有3个人参与故事估算，但是不要超过6个人。

新故事

新故事的出现有两种形式：新功能需求和既有故事的切分。一般我会根据新故事的优先级考虑何时进行估算。如果一个故事要在下个迭代中完成，那就得对它马上估算。不过，要是新故事在接下来几个迭代中都不会出现，再等等也无妨，直到有了足够的故事来证明召开估算会议的必要性。我发现估算会议上得到的估算值更为可靠，因为在那个环境中，大家都将精力放在估算之上。通过切分得到的故事有其复杂性：它们可能已经估算过了。我强烈建议在估算新故事时，不要考虑之前的估算值。如果一个故事因为其风险或不确定性需要切分，很有可能之前的故事是不靠谱的 忽略原先的估算吧。

不要用笔记本电脑

至少不要给开发人员提供笔记本电脑。把故事列表打印出来分发给大家，或者用投影仪投放在屏幕上，但是不要让开发者从自己的笔记本上读故事列表。笔记本总是从某些方面吸引开发人员的注意力，因此使得他们偏离会议的目标：得到有价值的估算。

必要的参与

这个建议非常重要。理论上说，除团队之外的开发人员都不能参与估算会议。也就是说参与会议的每个程序员都有可能要去开发被估算的故事。如果一个开发人员不喜欢估算某个故事，那我就不希望他们开发这个故事。当然，凡事有例外。对于新成员来说，我会给他们一周的时间来适应，之后再参与估算会议。不过，一般来说，拒绝参加估算会议的开发人员应该说明：有什么样更严重的问题等着他解决。

过时的估算

团队会改变，项目会变化，天有不测风云。不管是什么原因，估算都有可能过时。过时的估算毫无用处。要跟上过时估算，开发团队会有压力，而业务人员根据之前了解的进度，希望故事可以及时完成。估算过时与否并不重要，重要之处在于估算不再可行了，由之产生的计划也不再可靠。我参加过的项目中，所有的估算在 12 24周内都会过时。承认估算过时，而不要用不准确的信息安排计划。因此，我建议重新过一遍已经过了12周的故事估算。虽然这些估算可能没有问题，但是开发人员有机会提供新的信息，这对于整个业务来说肯定有所裨益。

小恩小惠

这个建议最容易做到了。为估算会议购买各种好吃的零食。科学证明：甜食会让人产生幸福感，而幸福感会带来协作。想让估算会议按照既有方向进行，这是最简单、最便宜的方式。不过要注意：好吃是关键。如果拿出来的零食在团队房间中已经存在，那就索然无味了。在最近参与的项目中，一想起来要开会了，我就会去面包店买刚出炉的什锦饼干。

感谢

我想特别感谢：Brent Cryder, Dennis Byrne, Fred George, Joe Zenevitch, Mike Ward, Sean Dora。他们帮我把这些想法固定下来而且不断改进，跟别人一样，我也肯定遗漏了一些做出贡献的人，请原谅我的疏漏。

关于作者

Jay Fields在ThoughtWorks工作，负责软件开发和相关的顾问工作。他热衷于发现和改进创新的解决方案。最近，他的主要精力放在领域特定语言（DSL）之上，而且已经交付了很多应用，使得领域专家可以顺利地编写业务逻辑。对于开发人员通过软件测试提升软件设计的成熟度，他也很感兴趣。

*速度：当项目的生命周期通过迭代组织时，用来计算一个迭代能够完成的工作的点数。比如：如果你在5个迭代中完成了20点，你的速度就是4。只要故事的估算之和是4点，你就可以在一个迭代之内完成这些故事（比如，一个估算为4点的故事，2个估算为2点的故事，4个估算为1点的故事等等）。

在InfoQ英文站文章后的评论里，读者dale moody补充了一个技巧 限制会议长度。他说：

超过30分钟后，我的估算质量就开始下降了。要是过了一个小时，我可能连自己的名字都不记得了，更不要说该我估算的故事标题了。 估算疲劳 会让人们状态下降。为了隐藏这个事实，开发人员们给出的估算会比较中庸，这样大家就不会再被迫去讨论故事了。

如果你发现有人出现了萎顿的状况，干脆叫停会议算了，感到疲倦的应该不只一个人。我发现，短暂的休息只能带来短暂的状态恢复，最好是等明天大家都充满活力 的时候再继续开会。再说，如果估算进行得太久，也许估算的就太多了，而领域专家、业务分析师、项目经理可能都还没有准备好。

读者Arnon Rotem Gal Oz对 独立投票 这个技巧进行了补充：

我们用手机。每个人把自己的估算在手机上按出来，然后我们会对比各自的估算。 ：）

读者keith gardner分享了他的故事估算技巧：

我最近换了工作，之前的工作是与团队坐在一起的，现在的职位要与分布式团队一起合作。同时我在帮现在的小组从瀑布式过渡到Scrum开发（效果看来还不错，因为我们每隔2到3周就要改变优先级。而且我现在的组织好像经常会改变优先级）。

我曾在故事估算会议上用过扑克式规划，也取得了一些成功。不过在之前的公司里，我们面对着下面这些挑战：

让每个人同时展示他们的估算卡片（展示估算卡片，还得同时，这比想象的要难得多）。查看所有的卡片，判断高低。确保每个人都把注意力放在当前的故事之上。当有人不在现场时（似乎总是会有这样的状况），尽量让他们也参与进来（当大家都已经写好估算之后，让这些不在现场的人先说出他们的估算，然后再让房间里每个人展示自己的估算。确保不在现场的人能够知道所有的故事细节，而且可以听到房间里的对话，并且能跟上大家的节奏）。我最近发现了一个免费的扑克式规划工具，我很喜欢它，网址是：http://planningpoker.com（由Mountain Goat Software提供）。我们也用Rally管理用户故事（http://www.rallydev.com/）。

我们的估算会遵循下面的步骤：

准备阶段。在规划会议前一至两天，产品负责人和scrum master会先把用户故事整理整理一遍（添加验收条件、确保有足够的细节、排定优先级）。准备阶段。在规划会议前几个小时，scrum master会将用户故事从rally导出到扑克规划工具中。我会安排优先级，因为我们将会议时间限制在一个小时，并且处理尽量多的故事。如果需要的话， 我们会有后续的会议来过更多的故事。如果完成了高优先级故事的估算（以及其他团队挑出来的任何故事），接下来会进入规划阶段，并排定下个sprint前要 开发的故事。我们会用电话会议服务进行辅助。也用过WebEx让大家看到同样的信息，不过最好让大家都可以展示他们希望给别人看到的信息，这样更有效率。工具可以促进并强迫每个人展示各自的估算。这样很好，去掉了很多问题（作为管理员的Scrum master可以输入最后的估算）。工具只显示目前处理的故事。在逐个估算这些故事时，对它们的问题和澄清会被录入到rally中。进行讨论时，有效的scrum master可以保证每个人都能有机会对故事发言，并且每个人都不会分散注意力。在达成一致意见之前，我们会进行几轮估算，而且会与不在现场的人讨论。工具可以跟踪整个会议中所有的估算。会后，我们会把估算数字录入回Rally中。我非常喜欢我们的这个过程，而且我个人觉得这比个人用扑克进行估算的效果更好。

读者Andrea Maietta对于如何管理估算选择的数值提出了自己的看法：

就像Mike Cohn在他的书里面指出的那样，我们选择斐波那契数列进行估算，而且觉得效果非常好。我们有从0到20的卡片，但是很少选择超过13的数字，因为这会留下至少5点的估算差值。

至于工具，我们用涂有颜色的纸，并切成有规格的纸片，其中涂上我们的数字。这样就得到了规划扑克。

我觉得选取故事估算的最大值是节省时间的一种方式，但对于小型团队来说，我觉得对被选中的值（和隐藏风险）进行简短的讨论，这有助于提升对于项目的整体理解。

读者Dave Rooney提出：

在大型团队中使用规划扑克时，我发现总是有一组人的估算比较低，一组人比较高，还有一帮人的估算介于中间。一般我会让提供高值和低值的人解释他们的想法，防止有人对故事了解得不完整。通常情况下，需安装的估算不一定是最高的，经常是中间的值。

对于他的说法，作者Jay Fields这样回应：

保持一致是最重要的。如果总是选择中间的值，依我看，这问题不大。进一步讨论应该会有效，但是要考虑两 点。第一，你可以得到更多信息，但是在这个时候这么多信息是不是真的有价值呢？我发现更多的讨论总是会使大家选择中间的值，但是也会带出更多信息，而这些 信息不是整个团队所需要的。不是每个人都需要知道每个细节。第二，你不会希望鼓励大的估算。有时人们会感觉一个值有点大，这个感觉通常是对的。如果你强迫 他们去解释，他们也许会给出更低的估算，而忽略自己的感受。当然，如果总是有人过高估算，这也没什么，还得要保持一致性。我觉得你的选择也不错，但是我个 人还是觉得选择最大的估算是最有效的方式，而且也能让参与者感觉良好。

对此，Dave Rooney也同意保持一致非常重要，他回应道：

如果给出高估算值的人确实发现了别人没有想到的东西，当然我们会选择更高的估算。

不过我有时会得到这样的回答： 我没怎么用过这个技术 或是 我不太理解需求 。对于前者，降低故事是有意义的。如果给出高估算的人来开发这个故事，可以让他们跟精通技术的人一起结对。对于后者，明显是由于这个人没有提出足够的问题，没有深入了解进行估算需要知道的东西。

所以，对于上述两种情况，我推荐用中间值。不过我同意，在大部分情况下，还是 最高的估算为王 ！

读者Vladimir POPOV指出：

我们曾用过2的幂进行估算，后来发现在项目级别来看，它有点过于 扁平 了，所以我们就用e的幂。有趣的是，斐波那契数列与e的幂非常接近。比如1、3、8、21、55 实际上，我们用到的复杂度也就这5级，最后一级用来识别需要重新估算的故事。

读者Martien van Steenbergen对于故事的排序提出了自己看法：

对于按照业务价值对故事进行排序，我使用 大家下注吧（faites vos jeux） 的方式，也是由玩扑克得到启示而产生的实践。

每个业务干系人（他们做决策，控制预算，也可能是用户）拿到10到20个筹码。所有筹码的价值相等。接下来，如果他们认为某个故事应该在接下来的两个sprint中开发，就会把筹码放在其上，并提出下列问题：

（在我内心深处）这样做感觉好么？这样做有意义么（是否理智）？这样做可行么（是否可以实现）？这样以来，下两个sprint中开发的故事就是基于他们的价值进行排序了。

接下来就让开发人员选择故事吧。

作者Jay Fields在评论中对于估算值的选择给出了新的解释：

Fred George，是我遇到的最好的同事之一，他喜欢用T恤的尺寸进行估算。这样做的优势在于：你无法对尺寸取平均值。但是我觉得有个问题：你没有办法用手表 示M，而是要用两个手指表示2点。我喜欢大家用1、2、4、8个手指进行估算。要是表示估算得用两个手的话，做估算的人就得考虑下为什么要用8点了。这通 常会得到一些关于故事的新想法 可能是技术也可能是业务的角度。我不反对使用斐波那契数列，但是这会让我不能给出10点以上的估算值。你可以使用1 5 级（就像Vladimir POPOV在之前的评论中提到的），但是我想即使用1 5级的方式思考，但是写在纸上的数字却可能会有所不同。这没啥问题，但我还是喜欢在思考、给出估算 值和记录估算值时，使用同样范围的估算数值。这样更自然，而且我也有很好的例子来证明。

读者Maurice Hager对于文中没有提到Delphi估算技巧表示惊讶，并认为这是一个不错的工具。

〔译注：通过Delphi方式进行估算，项目经理会把团队召集在一个房间中，并就项目有关事宜向他们进行阐述。大家会提 出各种问题，每个人都会写下来自己的任务列表和时间估算，同时注明自己对项目的预设条件。接下来，团队会收集任务列表并进行复查，看看哪些任务可以同时进 行。项目经理会把估算时间加在一起，得到项目的整体估算。可参考文章《》〕

看到此处说明本文对你还是有帮助的，关于“用户故事估算技巧”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！