为什么我们使用Story Points进行估算？

故事点 (Story Points) - 简介

---

Scrum指南告诉我们，估算应该由将要完成工作的人提供，但它并没有告诉我们应该如何提供估算。它把这个决定留给了我们。Scrum团队使用的一种常见策略是使用称为故事点的度量单位进行估算。但为什么要使用Story Points而不是几小时或几天或任何其他众所周知的时间单位？我们是故意试图混淆吗？在本文中，我将介绍使用Story Points的优缺点，并得出一个令人惊讶的结论。

什么是故事点？

“故事点是一个相对的度量单位，由各个Scrum团队决定和使用，以提供完成要求的努力的相对估计 “

为什么要使用Story Points？

故事点旨在使团队评估更容易。与其他产品积压项目 (product backlog items) 相比，团队只考虑产品积压项目需要多少工作量 (effort)，而不是查看产品积压项目并在几小时内估算出来 。

好的，所以它使评估更容易，但它有用吗？

我们无法对成本和可交付时间进行任何预测，至少直到我们从可能需要几个月的几个冲刺(sprints)中获得了速度(velocity)的平均值

使用时间作为度量单位有什么问题？

几百年来，我们有了标准的时间单位。为什么我们不能使用几小时或几天？好吧，简而言之，因为你的小时与我的小时不一样。

如果您要求两位开发人员估算相同的任务，您将得到两个不同的答案。虽然一些差异可能是由规范或理解上的差距来解释的，但事实是开发人员拥有不同的知识和经验，因此需要花费更多或更少的时间来完成相同的工作。

要求这两个开发人员评估完成一个产品积压项目(Product backlog item) 相对于另一个产品积压项目所需的工作量，并且您更有可能最终达成共识。

使用Story Points的真正原因

因此，到目前为止，您可能不相信使用Story Points的必要性。好吧，他们展示了完成不同产品积压项目工作的相对工作量，但这对任何事情有何帮助？在我们了解团队的速度之前，我们仍然无法预测产品积压项目何时可能完成。更糟糕的是，如果团队成员发生变化，速度会发生变化，我们将不知道新的速度是什么，直到一段时间。

所有这些问题导致许多人试图在故事点和时间之间建立关联，但正如 Mike Cohn 在他关于将故事点与小时相关的文章中 指出的那样，这并不是微不足道的。

但是，尝试将故事点数与小时相匹配是不容忽视的。重要的是团队可以在冲刺 (sprint)中完成多少个故事点 (story points)，称为速度 (velocity)。当你知道这一点时，你可以做出一些预测而且你知道什么，它们可能是好的。很好。

使用Story Points的真正原因是它们是准确的。

谁这么说？Jeff Sutherland，Scrum指南的合着者。在他关于为什么故事点比几小时更好的文章中 他这样说：使用故事点因此比小时更快，更好，更便宜，而表现最好的团队完全放弃任何每小时估计，因为他们认为它是浪费，只会减慢他们的速度。

• 冲刺增量与潜在可运输产品对比MVP与MMP
• 为用户故事撰写SMART目标和投资
• 什么是产品Backlog中的DEEP？
• 如何为Scrum项目撰写产品愿景？
• 如何使用Scrum Board进行敏捷开发？
• 谁在S​​crum中创建产品Backlog项目或用户故事？