如何在团队能力不同的情况下估计冲刺速度？

我们是一个由4个开发人员组成的小组，在Scrum中颇为环保。来自全国各地，我们经常请假几天或整周假回家。因此，由于年度休假，我们的团队能力从一次迭代到另一次迭代急剧变化，这导致一次迭代到另一次迭代的速度差异很大。在计划会议上估算速度时，我们如何考虑团队能力？历史数据将反映出截然不同的容量，我们不能等一整年才能得出估计速度的平均值。

这可能是一种简单的方法，但是为什么不将速度计算为completed story points * capacity或completed story points / capacity，取决于如何测量容量。如果以工时衡量容量，请使用秒。如果按每周40小时的百分比来衡量容量，请使用第一个。当您获得故事点时，您应该对给定冲刺的容量有一个很好的了解，并使用项目的历史数据来确定给定负载下完成的故事点。

但是，这做出了一些潜在的危险假设，例如将所有员工一视同仁-如果您的最初级的开发人员请假一周，或者在该领域和/或技术方面拥有最多经验的开发人员请假一周，则您的能力将是相同的数值，但对速度的影响可能会有所不同。

最终，在计划冲刺时，请基于历史数据使用专业判断。在这种情况下，请使用先前的速度作为其他估算方案（涉及团​​队）的输入。我也要谨慎一点-将更多的工作拖入sprint比取消执行任务的承诺要容易。

即使容量保持不变，速度也会变化。

因此，只要相信您的速度，它就会自己处理不同的容量，即假设您进入第3个Sprint，取最后两个完整Sprint的平均值来提交下一个Sprint。不必担心容量差异。

速度是一种指导，而非度量。只需将所有sprint的平均值（考虑标准偏差）和最差的三个平均值，最好的三个平均值相加，然后说：“我们一定会完成，我们可能会完成，我们不会这些都完成了。” 通过使用这三种速度和您的粗略截止日期在（完全估计的）积压工作中划出三条线（假设是12个冲刺和12倍，您的最差速度是75，12倍您的最佳速度是120，12倍您的平均速度是90。积压100点，即使是在最坏的情况下，也可以完成四分之三的工作，在最好的情况下，您可以钉住整个事情，而平均而言，您可以交付大部分）。

有了这些数据，您的PO可以在他必须拥有的东西，我们希望拥有的东西以及他不介意遗漏的东西上做出他需要的所有决定。

最终，情况发生了变化，需求不断涌现，而且情况将再次发生变化。不要为获得特定的数字而浪费时间，准确的范围就足够了。解决软件问题，而不是积压数学问题。