最近关于如何利用用户故事的相对大小进行估算的话题，已经在很多评论以及这个博客的留言中多次出现过了，那么我们就这个话题来讨论一下吧。下面的图表显示了一个公司的相关数据：
每一列的数据和每一对柱状图都显示了来自下方表格中对应的用户故事点数的数据。第一组数据是关于1个故事点数的用户故事的，第二组是关于2个故事点数的用户故事，如此类推。在第一组数据中我们发现，这家公司中完成一个1个故事点数的用户故事所需要的时间的中位数是21个小时。最短所需时间是6小时而最长所需时间是36小时，在上图中分别用绿色和蓝色表示，而中位数则由红色曲线表示。
让我们来看看2个故事点数的用户故事。从图中我们可以看到，中位数是52个小时，最短和最长的时间分别是31和73个小时。如果我们假设1个故事点数的用户故事的估算是准确的，那么我们应该预期2个故事点数的用户故事所需时间的中位数应该是42个小时而不是52小时。反过来推断，那么1个故事点数的用户故事所需时间的中位数应该是26个小时。在绝大多数情况下，估计都不是完美的。无论是从哪边开始推断都有所偏差，因为2个用户故事的中位数并不是正好是两倍的关系。
但是我再看看3个故事点数的用户故事。根据推算，对应的中位数应该是1个故事点数用户故事的3倍，也就是说应该是63小时，从图中可以看出实际是64，已经非常接近。
同理，5个和8个故事点数的用户故事的中位数应该分别是105小时和166小时，而他们的实际值是100小时和111小时。但是，等等，我们必须要对这两种用户故事进行一些调整。如果你使用的是我推荐的方法的话，你就会将这些数字看成是一个个水桶。8个故事点数实际上对应的是从6到8的用户故事。所以，如果你认为一个用户故事是6个故事点数的话，你不能把它放到5个点数的那一项里面，而是要放到8个点数的一项。
这就意味着，5个故事点数的用户故事实际上是对应4个和5个点数的用户故事。如果我们假设这两个大小的用户故事的数量是相等的，那么实际的平均故事点数应该是4.5。于是4.5×21=94.5个小时，在实际值101小时的5%的误差以内，还算不错。
由于图表中8个故事点数对应的是6,7,8三种大小的用户故事，我们可以推断平均故事点数是7。于是，中位数应该是7×21=147小时。然而，实际值却是111小时。所以，这个团队在进行8个故事点数的用户故事的时候肯定会比计划中有所偏差。
（在这里我想说点题外话。与其简单地推断21个小时就是1个故事点数所对应的时间，然后在后续的计算中使用，使用Excel进行线性回顾分析会是更好的办法。你可以观察复判定系数r-squared来检验得出的值是否合理。在这里我并不想深入探讨这些数学问题。但是我相信，这些数据一直到8个故事点数都会比较准确。）
我鼓励你在你的公司收集类似的数据，但是你必须小心。因为你要收集的是每个用户故事的实际时间，所以很有可能你的团队会比平常感觉到更多的需要在估计时间内完成的压力。然后，他们也许就会给自己预留更加充裕的时间。要是这样的情况发生的话，最终将影响到数据的准确性，违背了收集数据的初衷。所以，让团队看看类似上面的图表，然后向他们说明这是为了帮助他们。举个例子，上面图表中的团队可能会意识到他们也许将本来应该是5个故事点数的用户故事误当作8个故事点数了。（从数据上来分析，也许他们的估算是对的，只不过是当中包含了比较多的6个故事点数的用户故事而已。）
很多团队会发现他们对故事点数从1到8的用户故事的估算还是比较准确的，就像上面图表中的团队一样。使用这种方法一段时间以后，加上一些练习和校正，几乎任何团队都可以对13个故事点数及以下的用户故事进行较为准确的估算。至于超过了13个故事点数的用户故事，使用这种方法的时候必须非常小心，或者只能够用来回答一些比较粗略的问题，如：“这个项目的周期大概是几个月还是要一年？”
如果你收集了你的团队的相关数据，并且愿意和我分享的话，我将会十分感激。你可以把数据通过邮件方式发送到mike@mountaingoatsoftware.com。我一直在做这些数据的研究工作，因此如果我能够有更多数据会更好。
作者:Mike Cohn
原文地址：http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight
