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