几周以来，我一直在练习 Scrum 和用户故事估算，现在我正在尝试跟踪我们的估算，以了解它的效果如何。所以我创建了一个这样的表：
注意：高估 = 原始 - 完成
这对我没有多大帮助，因为我们的估算仍然不准确，而且每个 sprint 都会有一些剩余的工作。因此，高估列在解释我们的估计有多好时并不准确。谁有更好的方法来跟踪估计？
【问题讨论】：
从您的帖子中，我不得不假设您是以小时而不是故事点来估算您的用户故事？ （否则，我看不到您将如何检查您的估计）。
根据我的经验，这种方法是有缺陷的。相对估计已被证明是一种更好的估计用户故事的技术，而且 Scrum 的共同创造者之一 according to Jeff Sutherland 也更加准确。
以小时为单位的估算通常发生在任务级别。您可以在此处执行分析，但我会质疑您为什么要这样做。你会从中获得什么价值？
如果您的目标是帮助开发人员更好地进行估算，那么 Sprint 回顾会议就是这样做的合适场所。所做的估计将在开发人员的脑海中保持新鲜，并且可以检查低估/高估的原因并考虑任何调整（但是，让开发人员决定这是否是他们想要改进的领域 - 不要强加给他们）
总结一下：
【讨论】：
请务必按时召开 sprint 回顾会议。这是检查和采用的绝佳机会。在那里你可以讨论出了什么问题，在你的情况下是它的估计，并将其作为下一个冲刺的改进点。
我还会建议及时召开积压培训会议。假设您要进行三周的冲刺，然后将其减少到两周。我建议将您的 sprint backlog 项目（或子项目）设置为两天。这将有助于使您的估计更准确。
【讨论】：
我不建议在 Scrum 环境中跟踪已完成的工作或错误估计。以小时/天为单位的估算主要是作为 Sprint 计划会议期间讨论和探索任务的借口，其次是为了日复一日地跟踪 sprint 进度。为此，跟踪剩余工作就足够了。
如果团队低估或高估了，1/你没有多少值得信赖的改进，2/它不会影响由无论如何，团队最终和3/它在冲刺之外没有任何后果。
团队自然会根据速度而不是时间估计来调整他们在后续冲刺中的承诺。
如果你想听听我的意见，最好专注于改进工作本身，而不是改进你对工作的预测。
【讨论】：