对故事的Scrum重新估计

每天，站起来后，我和我的团队都会更新每个故事的估算值。我觉得我们的操作方式有问题，因此需要您的帮助。

这是我们如何做到：

故事A估算：24小时（每天8小时-我们使用“理想天数”作为衡量标准）

• 第N天：开发人员在早上开始处理故事A（一天结束前要完成8个小时的工作）
• 第N + 1天：故事A重新估算= 16小时（从第N天开始，从故事A中取出一个工作日）
• 第N + 2天：故事A重新估算= 8小时（从第N + 1天开始，从故事A中取出一个工作日）
• 第N + 3天：故事A现在应该完成。但事实并非如此。开发人员认为还需要3个小时才能完成。我们在白板上更新故事并进行相应的燃尽。
• 第N + 4天：故事A花了整整一天而不是3个小时！现在完成了。5小时的差额在我们的计划中完全无法解决。

我们应该如何每天重新评估我们的故事？

5小时的差异在我们的计划中是完全无法解释的。

是的，它隐式地说明了原因，因为以下任务被延迟。如果只为该开发人员提供燃尽图，您会注意到曲线在一天中一直保持“平坦”，而如果开发人员尽早完成它以承担其他任务，则该曲线将下降。

您在日常会议中进行的重新评估方式没有任何问题，重新评估的重点在于确定是否可以在冲刺结束时进行评估，而不是跟踪每个任务的确切延迟时间。Scrum中每天能够调整计划所需的全部内容可以指示Sprint的进度以及达到Sprint目标的距离（通常是燃尽图）。

您应该问的问题是：我们应该重新评估我们的故事吗？

我认为，在计算下一个速度时，应该让敏捷“魔术师”平衡一次迭代的低估和高估（这是更正值的唯一原因）。有关更多信息，请参见Mike Cohn的敏捷评估和规划。

但是，在某些情况下，您应该重新估算：您从某类工作中学到的东西会调整以后的所有估算。

例如。如果将一列添加到数据库估计需要一个理想的时间，但由于某种因素（没有人考虑过）而花费了3个小时，并且看起来该因素将在您每次向数据库中添加字段时适用。然后应调整所有此类工作的估算，包括您正在进行的估算。

我发现最有效的是：

• 按分数（或T恤尺码）调整故事大小。
• 随时重新估计产品积压中的任何故事（尤其是在进行冲刺计划之前）。
• 不要重新估计为此冲刺计划的故事-随时在站立时提出担忧，但不要更改估计值。
• 使用昨天的天气安排冲刺

如果故事以虚假的估算进入冲刺，则冲刺前计划的重新估算将使您在问题变成问题之前进行修复。如果故事因为团队过于乐观而花费的时间比预期更长，那么昨天的天气将使您步入正轨。

正如您在问题中所描述的，每天对剩余物的重新估计往往完全是虚假的。已完成/剩余的工作是一个伪造的数字，旨在使您看起来像在“足够努力”。更好的方法是问“您什么时候会完成”，并明确指出，如果故事存在问题，团队将加紧帮助。

我认为这不是问题。而是可能缺乏经验。您对Scrum的关注越多，就会有更多的开发人员习惯于提供更精确的估算。这是我们在5个月后实施Scrum的经验。

在计划扑克会议时，我们的开发人员建议对每个PBI和第一次冲刺中的每个任务进行非常不同的估算。但是，现在，我们在时间和估算上几乎相等。您使用Scrum多久了？如果不是那么多，请给它一些时间。但是，如果时间较长，则如@pdr所建议的那样，请考虑为风险较高的任务增加额外的余量。例如，每次我们的团队想要制作一块UI跨浏览器时，我们都会通过估算。因此，我们总是将跨浏览器任务的估计值乘以一个因子，以确保我们可以覆盖它。

在sprint期间重新估计已提交的用户案例是没有意义的。这只会浪费您的时间。您已经做出承诺，是否进行重新估计都没有关系。

不同的情况是用户故事没有致力于当前的冲刺。时不时地进行重新估算是很不错的（在计划之前，每个sprint不超过一次）。重新估算可能合理的情况可能是：

• 产品负责人更改了任何用户故事
• 产品负责人拆分或合并任何用户故事
• 产品负责人添加了用户故事
• 您还有一些其他知识，这些知识在上次用户故事中没有提供
• 您发现一些用户故事是相关的，并且您已经做了另一部分尚未提交的故事
• 等等

您不一定需要重新估计每个用户故事，但是您可以。为了进行完整的重新估计，您通常需要一些快速的方法。如果要估算10到20个以上的故事，规划扑克可能会非常慢，效率低下，令人厌烦，有时甚至也不准确。另一种可能是魔术估计。