如何跟踪Scrum流程中剩余工作的估算？

Question

我一直在练习Scrum和用户故事评估几个星期，现在我正试图跟踪我们的估计，知道它有多好。所以我创建了一个像这样的表：

注意：高估=原始 - 已完成

这对我没有多大帮助，因为我们在估算方面仍然不准确，每个冲刺我们都会得到一些剩余的工作。因此，高估列不能准确地解释我们的估计有多好。有人有更好的方法来跟踪估算吗？

Answer 1

从您的帖子中，我必须假设您在几个小时而不是故事点评估您的用户故事？ （否则，我看不出你将如何检查你的估计）。

根据我的经验，这种方法存在缺陷。相对估计已被证明是一种更好的估计用户故事的技术，而according to Jeff Sutherland是Scrum的共同创造者之一，也更为准确。

以小时为单位的估算通常发生在任务级别。你可以在这里进行分析，但我会问你为什么要这样做。你会从中获得什么价值？

如果您的目标是帮助开发人员更好地进行估算，那么sprint回顾展是正确的做法。在开发人员的脑海中做出的估计会很新鲜，可以检查低估/高估的原因并考虑任何调整（但是，让开发人员决定这是否是他们想要改进的领域 - 不要强迫它们）< / p>

总结：

• 考虑使用相对估算与用户故事级别的故事点等项目
• 让开发人员决定是否需要在sprint回顾展中改进他们的估算
• 如果您仍然觉得需要对估算准确度进行分析，请询问什么 您将从中获得的价值并与Scrum团队进行讨论

Answer 2

请务必按时举行短跑回顾会议。这是INSPECT和ADOPT的绝佳机会。在那里你可以讨论出了什么问题，在你的情况下它的估计，并把它作为下一个冲刺的改进点。

我还建议及时进行Backlog修饰会议。如果您正在关注三周的冲刺，那么请将其减少到两周。我建议让你的sprint积压项目（或子项目）为两天。这将有助于使您的估计更准确。

Answer 3

我不建议在Scrum上下文中跟踪已完成的工作或误估计。以小时/天为单位的估算主要是在Sprint计划会议期间讨论和探索任务的借口，其次是日复一日地跟踪冲刺进度。为此，跟踪剩余的工作就足够了。

如果团队低于或高于估计值， 1 / 那么你可以勉强改进它， 2 / 它不会影响产生的价值量无论如何最终的团队和 3 / 它在冲刺之外没有任何后果。

团队将根据速度自然地调整他们在后续冲刺中的承诺，而非时间估计。

如果您需要我的意见，最好专注于改善工作本身，而不是改善对工作的预测。