估计Scrum故事点的最佳方法是什么？

我喜欢计划扑克在任何项目开始时的工作方式，让您相互比较和讨论每个故事的细节。

我注意到的一个问题是，随着时间的流逝，随着您对问题领域的了解越来越多，您倾向于为每个故事投票更少的分数，即，一开始的故事价值为5或8该项目的价值现在可能值得3。

您如何以最佳方式避免或解决此问题？有更好的估算方法吗？故事应该始终保持不变，还是故事点减少？

我认为这不是大问题。

可能有两个明显的原因。一种是您正在经历一些轻微的通缩。另一个是您的团队实际上正在变得更快。（我希望是后者！）

无论哪种方式，都没什么大不了的。速度的两个主要用途是弄清楚在下一次迭代中要进行多少工作，并对较大的工作块进行交货日期的粗略估计。速度的逐渐变化都不会损害这两个方面。的确，如果提高速度来自于变得更好，那么您的新数字将更真实地反映团队的能力。

如果速度变化太快而无法舒适，那么标准的故事就是一种回应。在过去的几个月中，每个故事都选出3个故事来代表您使用的得分等级。将它们放在墙上进行估算的地方。然后根据您的估计，将它们用作您正在处理的故事的比较。这样可以减少估计中的漂移和波动。

从根本上讲，这并不是一个大问题，因为其中大多数都会被洗掉。总的来说，对估计输出的显式操纵将对该过程不利。当团队将注意力放在球上时，评估故事点最有效-您正在评估故事与其他故事的相对复杂性，并且只要您掌握了已完成故事的历史信息，您就可能会发现情况已经解决在长期。在这里，团队的凝聚力会带来收益，因为团队最终将选择方法和参考故事进行故事评估。

故事点放气可能是一个温和的问题，因为随着您对点数范围的估计被压缩，您开始失去有关微调速度的信息，并且压缩可能会对估计长期释放的长度产生负面影响计划（这是因为您要将所有故事的压缩所带来的错误乘以一个狭窄的范围）。总体而言，您希望将由于专业知识而导致的速度提高的结果表示为承担更多的故事点，而不是减少估计。解决该问题的方法是不断引用以前完成的估算，并确保您始终估算复杂性。永远不要说出您认为需要花费多长时间，只需将故事的总体难度与以前的故事进行比较即可。让' 例如，您有一个支持移动平台的应用程序，则必须移植到另一个应用程序。它类似于先前的端口吗？更难，因为平台的工具更差？更容易，因为您拥有更好的调试器？这应该可以帮助您估算，而不是因为您的团队擅长估算，此端口运行速度可能会更快。只要有一个问题，专注于复杂性就应该可以解决这个问题。