我不喜欢故事点。我认为这是我反对复杂性的一部分。您可以
在这里
一睹为快。
故事点被发明为业务和开发之间桥梁的支撑梁，后来被称为敏捷。
他们从一个以前没有的非常好的概念开始：故事。
还记得那些数百页的规范和详细的功能文档吗？通过敏捷宣言，我们决定我们更喜欢客户协作。在 XP 中，有一个客户在现场，所以时间不会浪费在编写那些文档、阅读它们、曲解它们以及在其中开发错误的东西上。
所以故事取代了故事。它不再是“应用程序允许的东西”，而且还有一个“为什么”元素。在 XP 中，这个故事被转化为 TDD 中的测试。多年后，故事会发现自己取代了 BDD 中的规范。用户将如何使用系统以及原因的实际示例。
现在在敏捷之前的日子里（不管你信不信，有时甚至在今天），一旦我们有了一个故事，下一个问题就会立即出现：什么时候完成？
开发人员讨厌这个问题。仅围绕这个问题就有一整场#NoEstimates 讨论。 （您可以 在此处 、 此处 和 此处阅读其中的一些内容）。
估计的功能障碍在于它被认为是一种承诺。因此，为了确保他们履行了这一承诺，开发人员需要投入更多时间来获得准确的估算。
故事点是解决这两个问题的抽象。它没有单位，所以它不能与任何承诺相关。如果你提出正确的问题（“这与我们上次做的事情相比如何”），它会在估算过程中节省大量时间。你只是比较事物直到它们基本相同，而不是单独分析每个故事。
看来我们所有的问题都解决了！
好吧，不是真的。
业务人员仍然想知道这个故事需要多长时间。不仅是故事，还有整个积压。答案很简单：为一个故事点分配几小时或几天。所以一个故事点会变成另一个单元。
这就像在同一个项目中测量摄氏度和华氏度。
这种转换可以通过简单的方式或困难的方式完成。当然，我们采取了艰难的方式。所以我们分析、测量和估计一个故事点等于什么，带走了故事点的第二个优势。
我们还使用新单元构建了单独的流程。在 Planning Poker 中，我们使用斐波那契数列来估算故事。那是该单位的另一个规模。这就像将摄氏度转换为非线性刻度。
然后我们有以故事点数衡量的速度。因为速度是根据估计的努力计算的，而不是实际交付的。所以现在团队是根据他们的估计而不是他们的交付来衡量的，以虚构的单位，具有不正确的值。这些值用于下一次估计。这就像把上个月的天气预报拿来应用到这个月，而不是打开窗户。
故事点并没有使开发人员免于回答“什么时候完成？”这个可怕的问题。它要求他们在系统之间进行两次转换，并以时间为单位返回答案。翻译只是浪费了更多时间。
我们可以用时间单位得出相同的结果。
最后，项目管理工具供应商给了我们另一种搬起石头砸自己脚的方法，我们只是完成了更多的工作、更多的困惑和更复杂的工具。
Ron Jeffries 最近被引用“我不确定我是否是故事点的发明者，但如果我是，我很抱歉”。
故事点在当时似乎是个好主意。它们变得越来越复杂并接管了我们的生活，使它们变得更加艰难。如果您使用的是故事点，那您就错了。