团队向前推进工作，磨合好的团队，迭代的长度也不变，我们就可以对团队的下一个生产阶段进行预测。
出于人类的天性，自尊心会让个人和团队把目标越设越高。同样，这种天性会让团队变得过于激进，后果就是，团队要么采取捷径以避免让利益相关方和自身感到失望，要么就是无法交付期望的结果。在努力达到目标的过程中，团队学习到以下事实：有的时候，努力会带来迅速的改善，特别是当团队开始通过采用新技能或者新技术来自我挑战来获得提升的时候。但有些时候新技术并不奏效，团队的绩效会保持原样甚至变糟糕。有时团队是为了高目标而高目标，原因可能是想测试一下极限，也许是无意识的。这些自己设置的绩效挑战可能在短期会有效，但是通常情况下，这种高水平是不可长期持续的，绩效会跌落回原来的水平。
某些组织中，团队会受到压力，去交付比他们自身承诺的更多的成果。比如“延伸目标”，或者”宏伟、艰难、大胆的目标” ，这些说法都是用来形容这种激动人心又困难重重的工作。要求团队完成这种目标将会破坏团队自治，并且忽视了团队为了提高工作效率而做的改善措施。
因此，大多数情况下，上一个迭代完成的估测点数，就是下一个迭代团队能够完成的点数的可靠参照物。
团队可以通过挑选出能匹配下一生产阶段的时间要求，生产状况等条件的工作，更好地管理利益相关者的期望。最近几个迭代完成的估测点数的平均值，我们称为开发团队的速度。因为速度是一个统计数值，有平均值和标准差， 团队应该期望一半的迭代会达不到“昨日的天气”， 另一半的迭代则会超过它。我们的目标是改善工作流程，通过排除外界对团队的干扰、确保产品负责人提供可实现的需求说明，以及开发团队采用优秀的核心实践等措施，来降低速度的偏差。
可以使用移动平均速度来消除偏差。多团队协同开发同一个产品的情况则可以使用总平均速度。如果某个迭代的速度的确提升了，可以考虑使用更新速度。
早在1980年代，Armstrong已经推荐团队“用昨天的数值“来进行预测。他的论文也相应地参考了Spyros Makridakis 和 Michèle Hibon所做的预测方法研究工作，这项研究也以“M-比赛”或“马瑞达克斯比赛”而著称。
——译者:Suzzi
校对:Adam
参考资料：
（1）A Scrum Book：66 Yesterday’s Weather
