故事点 (Sotry 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 进行敏捷开发？
谁在 Scrum 中创建产品 Backlog 项目或用户故事？