我猜想在很多情况下估计在某些时候被证明是错误的。因为一旦您深入了解待办事项的细节，您可能几乎总能找到一些您在计划期间没有考虑过的事情。这可能发生在任务级冲刺估计期间或实际冲刺期间。
在任务级估计期间，您可能会发现一个故事/待办事项项目的任务太多，因此需要调整初始估计。 你现在做什么？您是否回到产品负责人那里并告诉他他可能想要重新确定其积压项目的优先级，因为这需要更长的时间（甚至更少）？基本上这可能意味着整个团队需要回到故事级别的估计并重新调整故事？
在冲刺期间，您可能会发现实施需要比最初想象的更多的努力。 你现在做什么？您是否知道无法按计划完成冲刺，是否默默地继续冲刺？从现在开始，您将为所有估算添加“安全缓冲区”吗？
一般来说，SCRUM 如何从整体上解决估计精度问题？
如果我理解正确的话，SCRUM 开发团队有点“承诺”产品所有者，它将按计划交付。但这只有在他们准确估计的情况下才能做到。因此，估计似乎对 SCRUM 的成功非常关键，但也非常困难。
简单的事实是，估计精度是一个矛盾的术语。像独角兽一样，它根本不存在。根据定义，估计是不准确的。
考虑到这一点，Scrum 和其他敏捷方法试图绕过这个限制，而不是打败风车。在 Scrum 中，对产品待办列表项（用户故事、需求等）的复杂性进行先验估计，以便让产品负责人粗略了解他可以在即将到来的 sprint 中完成多少故事。在将 PBI 分解为任务后，每个任务都会根据他们认为完成所需的时间进行估算。一旦团队的能力得到满足，他们就会（稍微）更好地估计他们在冲刺结束时可以交付什么。
这些估计仍然不准确。
敏捷产品负责人处理这种不准确性的方式是降低交付产品的延迟成本。PO 以这样一种方式定义和优先考虑他的故事，即他尽可能早地交付产品中最重要的部分，并尽可能早地创建一个（仍然不完整的）可用且有价值的产品。这样，任何没有按时完成的（冲刺结束或发布日期）仍然是可以交付的最佳产品，并且通常可以在时间之前创建足够好的发布，其余的，交付最不重要的功能小批量，很快。
这就是 Scrum 处理估计（不）准确性的方式。
一般来说，SCRUM 如何从整体上解决估计精度问题？
通过即时调整。您将故事点分配为大小和复杂性的度量。您会尽自己最大的努力在规模和复杂性相当的任务之间以类似的方式分配分数。
在最初的几个 sprint 中，你不可避免地会出错。随着时间的推移，您可以根据整个项目的“速度”来调整未来的估计。
这个概念是您创建一个反馈循环来校准该 sprint 的故事点的价值，并且您接受不确定性。在 Mike Cohn 的书Agile Estimating and Planning中有一个很好的讨论。
因为一旦您深入了解待办事项的细节，您可能几乎总能找到一些您在计划期间没有考虑过的事情。
估计中遗漏的任务是开发项目中第二个最常见的估计错误来源（第一个是......不断变化的需求！）[1]。这也是普遍“计划谬误”的一个可能根源。敏捷过程倾向于反对提前过早分解任务。
然而，管理这种风险的常用方法是建立估算清单。McConnell 的软件评估：揭开黑色艺术的神秘面纱是一个很好的资源——表 4.2、4.3 和 4.4（第 44-45 页）是您自己的清单的绝佳起点。
[1] van Genuchten，米歇尔。“为什么软件这么晚？软件开发延迟原因的实证研究”。IEEE 软件工程汇刊，1991 年 6 月。
Scrum 出色而轻松地处理估计。你说“作为一个整体”，但你说的是一个单一的冲刺。您正在谈论在一个冲刺上做出的承诺。想象一下：在第一个 sprint 上做出的承诺失败了，在第二个 sprint 上做出的承诺失败了。现在第三次冲刺会发生什么？你会在什么基础上做出第三次冲刺的承诺？回答你的问题就是这个基础
如果你在第一个 sprint 中的承诺实现了呢？那你就走运了！简而言之，Scrum 不需要你的估算技能。没有人要求你承诺/承诺。无论如何，您从来没有足够的时间进行估算，那何必呢？:)
但在瀑布中却恰恰相反。你有时间，你承诺，你有责任，你移动地球来信守承诺。
估计过程是 SCRUM 中最难的事情。有时可能需要长达 1 天的时间与团队一起坐在会议室并讨论需要付出哪些努力才能完成每个特定的故事。甚至不希望在几个第一个冲刺中得到准确的估计。您应该接受这一事实并继续前进。根据您的故事中有多少细节以及团队一起工作的时间长短，这个过程会从一个冲刺到另一个冲刺变得更好，并且估计会更准确。到目前为止，您可以只计算速度或将 0.5 作为您团队的当前速度。在完成第一个 sprint 后，您将获得更准确的速度，然后可用于构建下一个 sprint 的范围。
我的团队在项目一开始就很难给出准确的估计。一个项目中没有我们可以依赖的东西，没有架构，而且系统又大又复杂，所以每个人都不敢给出任何估计，因为没有人知道究竟应该建造什么。我们通过将系统分析师 (SA) 介绍给我们的公司解决了这个问题，他们正在分析所有传入的请求并且不会将它们传递给开发，直到从业务角度来看一切都清楚了。SA 的主要目的是了解新功能，了解如何实施并提出高级别的解决方案，同时考虑到对已实施功能的依赖关系，并牢记我们计划在即将到来的冲刺中实施的功能。完成初步分析后，SA 创建故事并将其添加到待办事项中。然后这些故事传给设计师。他们设计屏幕并将它们附加到故事中。之后，故事会提交给产品负责人进行审批并设定商业价值。
上述所有这些步骤大大减少了整个团队在估算会议上花费的时间。现在，当会议开始时，我们几乎拥有所需的一切。每个故事都有详细解释，开发人员可以看到它如何影响现有功能并查看设计，因此现在很容易只关注技术问题。因此，正如我们构建 SA 的过程中得出的结论，设计师正在研究计划用于下一个 sprint 的功能，而开发人员和 QA 则专注于活跃的功能。这使我们能够在积极的 sprint 结束时分析所有故事并为下一个故事进行设计。