哈Ha！ 我向您介绍Mike Cohn撰写的文章
“为什么我不使用故事点进行Sprint计划”的翻译。
如敏捷评估和计划中所述，我非常喜欢评估产品积压的故事点。 但是，我还建议在数小时而不是故事点中评估冲刺积压。 为什么这种明显的矛盾？ 之前我写过有关原因的文章。 我建议对不同的积压使用不同的度量单位（点和小时）。
但是经常有人问我一个相关的问题，我想在这里问：
我很好奇您为什么不使用故事点进行冲刺计划。 我认为，衡量故事点速度的目的部分是为了确定我们可以在冲刺中采取（或修复）多少。 您是否仅将故事点用于长期计划（例如发布计划）？我没有将故事点用于冲刺计划，因为故事点是一项有用的长期措施。 但是，积分在短期内没有用。
团队应该说：“我们的平均速度为20个故事点，还剩下6个冲刺，所以我们将在这6个冲刺中完成大约120个故事点。”
团队说：“我们的平均速度为20个故事点，因此我们将在下一个冲刺中完成。” 这是行不通的。
假设篮球队处于赛季中期。 迄今为止，他们已经打了41场比赛，平均每场得分98分。 应该说：“在本赛季的剩余时间里，我们平均每场比赛能拿到98分。” 但是他们不应该在任何特定游戏之前说：“我们平均有98个，所以今天我们将取98个。” 这就是为什么我说速度是有用的长期预测指标，而不是有用的短期预测指标。
速度因冲刺而异。
这就是为什么我希望团队通过查看产品待办事项，选择他们可以做的最重要的事情，将产品待办事项的这一要素/用户故事分解成任务并评估任务，询问自己是否可以采取行动来计划他们的冲刺承诺发布该产品的待办事项，然后重复执行，直到完成。 没有讨论故事点。 没有讨论速度。 这仅仅是义务的问题，我们通过将产品积压的点分解为任务并对其进行评估来决定可以实现多少。
当团队以这种方式完成对冲刺的计划时，他们不知不觉中追求的故事点的数量可能应该接近其平均值，但是它将改变。
从一次冲刺到下一次冲刺，团队将执行大约相同的小时数，这也是事实。 我使用“容量”一词来表示此小时数，因为速度是指计划或已完成工作量的度量，如用于评估产品积压的单位所示（我建议使用故事点） ）
作者简介：Mike Cohn是Scrum软件开发方法论的作者之一。 他是敏捷联盟和Scrum联盟的创始人之一。 他专注于帮助公司实施和改进对敏捷流程和方法的使用，以创建高性能团队。
参考：
敏捷评估和计划 ，Mike Cohn，2005年。
PS：您是否按小时或故事点来评估sprint积压工作？