我曾经连续做过三个项目，没有对用户故事估点，而仅是简单的计算用户故事数量。我非常倡导这种方法，接下来我来解释下为什么。
我也算是一个“估算通”，有十年以上的估点经验，使用过功能点，用例点，构造性成本模型（COCOMO），故事点等进行过估算。随着时间流逝，我渐渐感觉到在早期估计的越多，反而估计的越不准确。除此之外，耗时的、所谓的“科学”的估点实践，往往会对需求的确定性产生错误的期望。下面这个场景是否很熟悉？
PM：你原来的范围是100个点，但是现在变成130个点了，所以你们要砍掉30个点以确保能够按照原定的时间发布。
客户：但是范围并没有变啊，从一开始就是这30个故事，没有变化啊！
PM：是的，但100个点已经变成130个点了，因为我们现在对复杂度有了更多的了解。
客户：但这是同样的范围和业务目标啊，我们并没有改变什么。等等，我不觉得这个故事值5个点，我觉得它更像3个点。我们重新过一下之前的估算结果吧……
我们都知道这个场景是什么样的，业务人员觉得被我们“膨胀”出来的点愚弄了（在他们看来，这跟范围无关）。
在过去的三个项目里，我计算了平均一个点所需要的天数及用户故事的标准差。然后，再计算平均一个故事所需要的天数及标准差，结
现在，我更倾向于使用下面两种方法和客户沟通：
1. 在确定发布范围时，不是依据用户故事来确定，而是依据我们将要达到的业务目标和交付的特性确定。
故事点数代表着三个方面的范围：
（1）特性/功能
（2）丰富程度/可用性/深度
（3）技术复杂性
然而客户通常只考虑第一点。当因为另外两点，我们说“范围增长”的时候，客户往往迷惑不解，因为他们觉得自己的业务目标并没有改变。
2. 依据我们预测可以交付多少个故事来讨论范围，并规定所有的用户故事不能超过某个阈值(X天)。
举例来说，当发现一个故事的交付时间可能要超过X天时，团队就不要去开发这个故事。所以，如果“范围”（上述三方面之一）增长时，故事就要拆分，排在最后面的就要丢弃。
这种方法不仅仅使这种沟通更为顺畅，而且能够让人们关注于简化后两方面的需求——它们并不“直接”与业务目标挂钩。这样以来，客户实际上得到了更多他们所认为的“范围”（特性/功能）；而我们则不用陷入无休止的关于点数和尺寸的讨论中。
总结
我的确认为，团队采用估算的方法是一个逐步演进的过程：
1. 按工作量（天，周等）来估计
2. 按点数来估计（用例，故事点等）
3. 按故事/卡片数量来估计。为了让这种转变更为顺畅，我通常会说，“让我们假设所有故事都是3点，如果不是，就拆分。”，然后用3乘以故事数目。这种方式引导团队走向正确的方向——使用更小的工作单元，更易做到持续交付。
4. 彻底抛弃估算，持续交付，关注交付周期（cycle time）。
要迈向一个新的阶段，必须要得到相关决策人的认同。我曾经跟客户有过非常开诚布公地讨论，“我们可以一直玩这种点数游戏，但最终您的业务目标无法达到，您更愿意采取哪一种方法呢？”有时，他们不置可否，还持续在点数上做斗争，所以就这样一直争，直到某一天我们能改变这种情况为止。
常见问题：
我喜欢用交付周期和特性做度量。但是，在交付周期趋于稳定之前那段时间（通常很长）你如何处理？
没有银弹。（预计的）交付速率（velocity）或者（预计的）交付周期可以帮助你预测在一定时间内，可以交付多少。
1. 如果故事大小各异，那么我常常会与开发人员模拟两三个迭代，问他们可以交付哪些用户故事，通过计算每个迭代所交付的总点数，推算出每个迭代的交付速率。
2. 如果故事的大小都差不多，我会只计算故事的数量，并让开发人员估计一个故事需要多长时间能完成开发（dev cycle time）。然后通过
（开发人员数目x 给定的工作天数）/估计的交付周期
来推算出我们能够完成多少用户故事 （需要考虑到关键路径以及故事之间的相互依赖）。这种方法也可以用来验证交付速率。
无论如何，我都会询问客户对于现有已知的范围和复杂度，他们所看到的交付风险；他们对当前用户故事的理解是什么？有哪些未知的工作？他们觉得应该预留多少点/故事/范围预防风险？我通常的经验是，0-10%的预留是不现实的，20-30%是可以接受的，如果项目中一切都是未知的则需要大于30%的预留。然后他们会提供一些数据，我会给出一些建议。当一些未知的事情逐渐摆上台面时（故事数量或点数发生变化），往往更容易展开相关对话。
在做发布计划的时候，我一般会使用与业务产出目标相关联的史诗故事（epic）或者特性（feature），然后将它们拆分成用户故事，并检查拆分出的用户故事是否真正能带来相应的业务价值。
因此，用户故事的选择性淘汰就会很自然地发生。当这一切趋于稳定的时候，我会开始持续交付和交付周期相关的沟通。
每个人都建议你将用户故事拆分成同等大小，但我发现通常这些故事之间还是会有不小的差异。你做到了均等地拆分了吗，还是你觉得无所谓？
某种程度上，我认为其实无所谓。我发现这种差异从0.33天/点到3天/点不等，而且越后期的故事，相对于点数所意味的复杂度，越显得简单（因为有了更强的确定性）。这种落差令我深思。从项目范围管理的角度讲，单纯的讨论点数并没有实际价值，因为我通过计算故事的数目一样可以得到大概相同的结果（如上图）。并且这种只计算故事数目的方法，还不会让客户对我们已经确认的东西产生错误的期望。
如果某些人还是怀疑上述这种观点，那么试试“把每个故事标为3个点（我假设平均起来每个故事大概是3个点），这样就不会有差异了”。这种方法用起来效果就好像我们要争论2个点和3个点之间的差别一样好（或者坏）。而且，我不会把大于8个点的故事（或者需要多于5天才能完成的故事）放到backlog里，因为这样的故事大小更多地反映了风险而不是复杂度。
对于我来讲，估算会议的价值在于让整个团队对于项目范围，解决方案，风险和复杂度有个整体统一的认识，因为不同的人在讨论和评估同一个故事时，所理解的点和大小是不同的；并不在于最终所得到的实际数字。
免责声明：本文内容仅表明作者本人观点，并不代表Thoughtworks的立场