咨询师工作最大的好处之一，就是可以尝试很多种不同的想法，并可以把其中能够发挥作用的部分添加到自己最喜欢的流程之中。我发现有些用户故事估算技巧十分好用，希望通过本文对其进行详细介绍。
用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周的故事估算。虽然这些估算可能没有问题，但是开发人员有机会提供新的信息，这对于整个业务来说肯定有所裨益。
小恩小惠
这个建议最容易做到了。为估算会议购买各种好吃的零食。科学证明：甜食会让人产生幸福感，而幸福感会带来协作。想让估算会议按照既有方向进行，这是最简单、最便宜的方式。不过要注意：好吃是关键。如果拿出来的零食在团队房间中已经存在，那就索然无味了。在最近参与的项目中，一想起来要开会了，我就会去面包店买刚出炉的什锦饼干。
| 
