多久时间？如果查尔斯·巴贝奇（Charles Babbage）能够构建他的分析引擎，那么艾达·洛夫莱斯（Ada Lovelace）可能是第一个遇到这个恼人问题的开发人员。乍一看，这实际上是一个合理的问题，特别是当涉及非常小的且易于管理的任务时，并且答案在小时范围内。不幸的是，开发人员经常会因为更大的事情而被问到这个问题。如果此时并非所有需求都清楚，更不用说理解了，那么您如何回答这个问题？计算出来是工作中最重要的部分，所以你要尝试估计它。任务越不明确、越复杂，这种估计就越像在看水晶球。我们希望我们的估计不会被视为承诺，并且我们一直希望如此。
幸运的是，这一点已经在敏捷世界中得到了认可。工作量不再以绝对时间来估计，而是与标准任务相关并考虑到复杂性，这称为“故事点”。从一个冲刺到另一个冲刺，已完成的积压项目的故事点（SP）被计算出来，由此确定团队的“速度”。对项目进度和成本的预测就是基于这个速度。
至关重要的是，在团队和所有利益相关者之间，SP 仅被理解 列表构建mlm 为各自团队的计划变量，而不是其他任何东西！
已交付 SP 速度 总 SP 转换量 标准差 总 SP 预测 预测 SP 最小值 预测 SP 最大值
从表中可以看出，计划了 12 个冲刺 - 目前正在进行第 5 个冲刺。根据过去的冲刺，假设团队速度为“27”。速度是迄今为止每个冲刺“交付”的 SP 的平均值。基于此值，现在可以相对轻松地为即将到来的冲刺创建预测。简单地假设每个冲刺可以继续交付 27 个 SP。由于对未来的预测涉及一定程度的不确定性，因此另一个重要值是标准差。减去和加上标准差会产生悲观和乐观的预测。这意味着：悲观地说，每个冲刺可以交付 22 个 VP，最乐观的情况下可以交付 32 个 VP。因此，在第五个冲刺开始时，可以假设第十二个冲刺将实施总共 261 到 357 个 SP。当然，预测并不是对未来的精确预测，就像估计一样，预测也依赖于稳定的基础。主要区别在于透明度。
挑战和绊脚石
尽管计算预测很简单，但仍然存在一些挑战：
如何在 Sprint 1 之前获得预测？
如果团队估计该功能没有产品积压项目，您如何对功能 X 做出陈述？
SP 是在什么基础上确定的？如果团队更改了用于估计的参考基础怎么办？
当每个团队使用自己的参考基础进行估计时，这在规模化环境（例如 Nexus）中如何发挥作用？