假定你知道你团队过去一年中的平均速率是每两周一个迭代，6个故事点。没什么有趣的事改变了（同一个团队、同样的问题域、缺乏假期……），你认为下面问题的正确答案是什么呢：
1）在接下来的半年有多少故事点将被完成？
2）在接下来的4个迭代有多少故事点将被完成？
3）我们估计最后一个故事点是6分，那么我们应该邀请财富100的CEO下月来做产品发布吗？
我对第一个问题的答案会是：
1）6个月=13个迭代，每个迭代平均是6个故事点，因此我们将完成13*6=78个点
2）4个迭代意味着 4*6=24个点
3）每个迭代平均是6个故事点，所以在最后一个迭代我们能做价值6点的业务，所以为什么不呢？
但是和往常一样，在我们业务线上，答案应该是“看情况”。
假设过去团队每个迭代的故事点如下：
6，6，6，6，6...6
如果是这种情况，我会说上面的答案很可能是正确的。因为团队永远都完成了6个点，那么有什么胜算不能完成下个迭代的6点呢？
但如果历史记录是这样呢：
11, 11, 1, 1, 1, 11 … 1, 11
平均故事点仍然是6，但下一个迭代的点会是“1”或者“11”吗？在未来6个月你仍然会感到很舒适。历史显示了一连串的某个迭代中11和1的可能，每个大约50%的可能性。所以直观地说我们会完成78个点，给予或得到5个。4个月前预测是棘手的，但是如果我们减少可选功能形式上的马虎，也许只要一点儿加班我们仍然能舒适地准时交付。
然而预测下一个迭代的结果是可怕的。一连串的1与11的迭代产生了一个平均值为6点，且平均相差为5。如果发布要求完成6个点，我们就是在处理一个很大的风险。团队不应该提交到6个点，但更重要的是产品所有者甚至不应该要求他们提交到6个点，如果我们碰巧遇到一个迭代为1的点，那么再多的加班或强制或者无论如何也要保存这个版本将是无济于事。
想象你在众多高薪高管前演示你软件的新版本，现在答案是什么呢？就我而言我会说这些问题的正确答案如下：
1）6个月，78个点应该没问题
2) 4个月，24个点应该没问题，可是仔细考虑优先级以及确保在必要时丢弃一些东西会更明智。
3）2周，6个点，没门儿。