故事点是一种非常简单的工具，旨在简化发明者不相信的流程（估算），或者也许更确切地说，
故事点更看重交付而不是预测。
故事点的目的是提供对完成某项工作所需努力的快速（强调是快速）、不紧不慢的衡量标准。
这里想法是：
你问某人时间估计，他们犹豫不决，花 10 分钟告诉你免责声明，然后你仍然会得到一个乐观的估计。不仅如此，开发人员 A 的 4 小时估计与开发人员 B 的 4 小时估计不同。而且由于开发人员 C 是新手，他们的估计可能会被夸大，而开发人员 D 从 Jesus 的菜鸟年起就在这里，会给出一个低得多的估计。因此，我们不会询问实际时间，而是询问工作量的相对估计。
分配点数的最佳方法是进行相对比较。假设我使用斐波那契数列（用于 shiggles），假设我为第一个项目赋予中值 8。现在，下一个项目比第一个项目小还是大？更小？只有一半小？不是吗？好的，将其设为 5，然后我们继续。快。我们这里不追求精确度。
引入斐波那契数列的主要原因是：希望我们能够消除关于 4 点和 5 点之间差异的任何愚蠢争论。同样，我们希望快速完成这项工作。
点数不代表时间，但是，如果你跟踪项目的完成情况，你可以使用消耗率再次提供进度的直观说明。例如，如果我有 100 点的积压工作，并且我完成了 13 点的项目，那么我可以制作一个 WAG，表明我大约完成了 10%。
请注意我在所有这些中强调的是：快速、粗糙等等。如果您需要精确的预测，则不应该使用点数和烧钱率。
重要的是要记住，提出这个方案的人/人们的工作方式是持续交付，一点一点地交付，首先致力于客户认为最有价值的东西。
他们更关心通过可靠的交付来建立信任，而不是准确预测何时完成。
他们实际上是在对客户说：
- 听着，不要相信我们或我们的预测。
- 相反，看看我们每两周（或大约）交付了什么，如果这让你满意，那就继续吧。