故事点有两个目的：
- 1：强迫团队讨论并就工单的范围达成一致
- 2：让产品经理大致了解完成一组工作需要多少个 sprint，以及每个 sprint 可以完成多少工作。
对于利益相关者，甚至不会向他们提及故事点。
他们唯一需要知道的是团队估计完成他们想要完成的工作需要多长时间，并且 PM 应该在 sprint 中交付该估计，而不是几个小时或几天。
如果他们希望更快地完成，PM 应该与利益相关者和团队一起缩小范围，直到团队认为它足够小以适应交付时间。如果他们希望它在不到一个 sprint 中生效，则需要再次缩小范围，直到团队确信它可以按照指定的时间交付。
以这种方式工作需要坚定并与利益相关者就您的团队如何完成工作保持一致，并且还需要并非所有组织和团队都具备的信任水平。
原因：
人们会通过估计复杂性而不是时间来推动讨论。他们会使用团队绩效的历史数据将复杂性转化为时间。
然后有人争辩说团队将能够比过去更快地工作，这种说法通常没有证据。
但是：
构建复杂的软件通常需要比人们想象的更多的时间，因此，利益相关者通常期望付出更少的努力，并且无法合理化支出超过特定金额。
然后怎样呢？
在这些情况下，请与您的利益相关者讨论：
- 为什么估计的努力是这么多？
- 故事的哪一部分花费的时间最多？
- 最大的未知数在哪里？
此外，讨论以下方法：
- 分割故事并分多个部分交付
- 尽早验证每个部分，最好使用原型
想办法把故事的部分内容排除在外，尤其是那些需要大量努力且价值最低的功能。
因此：
- 那么为什么我们不能协商并决定时间和故事点之间的比例呢？
- 那么为什么故事点和小时之间没有一对一的映射呢？
答案：
时间和故事点之间的关系是衡量的，而不是协商的。它基于团队过去的表现来预测未来。
它类似于天气预报的工作方式。气象学家利用他的知识和观察数据来预测天气。同样，开发团队使用他们的知识来估计工作量，并观察先前冲刺的速度来预测预期的工作量。
因此，当利益相关者过来并开始提出这些问题时，您需要解释故事点的工作原理以及如何有效地使用它们，因为误用估计会降低团队的速度。
最好办法：
如果你还没有向利益相关者介绍“故事点”这个概念，那就不要这样做。只需使用人们更熟悉的概念：
- 功能 A 可以在 4 月交付 - 可能的时间范围
- 到下个季度，我们将能够交付..