最近的一条微博引起了我的兴趣：为了充分披露，这符合我自己的想法。我一直怀疑故事点并不是一个评估sprint能力的好工具。。。但我确实认为它们是一个潜在的有用的工具，有助于判断故事的范围是否正确如果你让团队看故事，他们都同意故事的要点，例如，每个人都说是8或13（如果你用的是斐波纳契数），那么说明每个人对故事的范围有着合理的共识。另一方面，如果一个人说2或34，那么这应该会引发一场讨论，为什么他们的估计是不同的。通常，原因是因为在故事范围内还有其他需求需要考虑。我还怀疑，如果你的故事很大，以至于每个sprint通常有1到4个故事，那么故事点可能是sprint容量规划的一个好工具。我怀疑大故事数量少的话，故事大小会有更多的变化，因此故事指向可能会有用。。。当然，我工作过的每个团队都有小故事，而大故事最终都会被分解。在过去的10年里，我参加过的典型团队，似乎每个sprint至少要写8-10个故事（专注于少数"史诗"。。。但我们不要开始争论！）不管怎么说，twitter上的说法并不是真正的证据。。。但twitter并没有很长时间提供：所以我们至少有一个数据点，这也证实了我的偏见！那么，我们如何通过收集实际结果来解决这个问题呢？这是我的行动号召。如果你有至少5个来自同一个团队的连续冲刺，请填写此表格。一旦我有足够的数据，我会发布一篇后续的博客文章和分析！Stephen Connolly在软件开发方面有超过25年的经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。斯蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。在Twitter、GitHub和他的博客上关注Stephen。