在本文中我想讨论一下最近经常被提及，几乎每个月都要被问到的一个问题。这个问题就是我们如何能够在没有可参考的历史数据的情况下，估算完成整个产品待办列表中所有项目所需要的时间。
我的建议是，在没有能够试行第一个Sprint之前，不要轻易给出答案。但是，我们总是要应对各种特殊情况的。在我们无法试行一个Sprint的情况下，可以举行一到多次的承诺驱动的(commitment-driven)的Sprint计划会议，然后根据这些数据来预计可能的速率。
当然，有的人总是喜欢使用小时，而不是速率，他们希望能够估计出完成产品待办列表所需的小时数，从而估算出整个项目周期（然而通过速率反而能够更直接的估算项目周期）。但是，既然这是一个普遍问题，我就希望能够解决它。
下面是经过我简化和提炼的实际问题：
我们没有历史的速率数据。我们有一个包含300个用户故事的产品待办列表。所有的用户故事都已经完成估算了，大多数都在3到13个故事点数左右。下面的方法合理吗？
1. 随机选择40个用户故事。
2. 把这些用户故事都分割成任务，然后对人物进行估算。
3. 然后可以得出每个用户故事的平均小时数。
例如，假设我们随机选择了40个用户故事，总共有150个用户故事点数，然后通过估算，完成这40个用户故事总共需要600小时。那么我们就可以得出每个用户故事点数大概是4个小时了吗？
嗯，是的，但是这种方法有下面两个问题：
1. 千万要记住故事点数和小时数并不是对等的关系，不能相互转换。我们不能够像上面的例子那样说1个故事点数就等于4小时。1个故事点数大约等于4个小时加上标准差，假设是45分钟。这就是说，在68%的情况下，1个故事点数等于3个小时15分钟到4个小时45分钟，在98%的情况下，1个故事点数等于2个半小时到5个半小时，也就是2个标准差。
2. 以上的方法假设1个故事点数的用户故事和13个点的用户故事是按照相对估算的。也就是说，如果1个故事点数为1的用户故事如果需要4个小时，那么一个13点的用户故事就需要13X4=52个小时。由于各种原因，这种推断并不成立。根据我收集的很多团队的数据表明，正如我们所预期的一样，团队并不是完美的。
那么我们怎么样才可以解决这些问题呢？第一个简单的解决方案就是，我们计算出每种大小的用户故事所需要的平均小时数，而不是把所有大小的用户故事合起来一起计算。例如，在上面的例子里40个用户故事总共是150个故事点数和600小时，然后得出每个点数等于4小时的结论。但是，如果我们把所有故事点数为1的用户故事来做计算，我们有可能会发现1个故事点数等于3.2个小时。同样的道理，我们可能发现2个故事点数的用户故事可能是1个故事点数等于4.3个小时，而用3个故事点数计算的时候，1个故事点数等于4.1个小时。
然后，我们就可以将平均小时数和对应的用户故事个数相乘得出每种大小的用户故事所需要的总时间。如下表所示：
| 故事点数 | 每个用户故事对应小时数 | 用户故事个数 | 总时间 |
| 1 | 3.2 | 5 | 16.0 |
| 2 | 8.6 | 8 | 68.8 |
| 3 | 12.3 | 7 | 86.1 |
我们首先要注意的是，在上表中的第二列是每个用户故事对应的小时数而不是每个故事点数对应的小时数。一个故事点数为2的用户故事每个故事点数等于4.3小时，所以一个这种大小的用户故事总共需要8.6小时。
这个表格告诉我们，故事点数为1的用户故事一共有5个，每个需要3.2小时。最后把最后一列的总时间相加就是170.9个小时。
在这里需要注意的是，这种方法会包含所有在分割任务和估算时间中的缺点。由于通常团队会无法一次过确认所有任务，所以这种方法只能估算出能够在会议上找出的任务所需要的总时间。因此，这种估算方法将需要后续的调整工作。我将会在后续的文章中讨论对这种简单方法的改进方案。
作者:Mike Cohn
原文地址：http://blog.mountaingoatsoftware.com/estimating-a-full-backlog-based-on-a-sample
