什么是Scrum中的速度 (Velocity)?

原创英文文章：What is Velocity in Scrum?

Velocity是一种非常简单，功能强大的方法，用于准确衡量Scrum开发团队持续提供业务价值的速度。这表明Scrum团队在Sprint团队期间将产品Backlog的平均数量转化为产品增量，由开发团队跟踪，以便在Scrum团队中使用。因此，要计算敏捷团队的速度，只需将迭代中成功交付的功能，用户故事，需求或待办事项的估计值相加即可。该团队应该：

• 预测特定日期可以交付的范围。
• 预测要交付的固定数量范围的日期。
• 在定义我们将为sprint提交的范围数量时理解我们的限制。

Scrum Velocity示例

在完成前几次迭代之前，有一些简单的指导方针可用于估算Scrum团队的初始速度，但在此之后，您的团队可以使用经过验证的历史速度估算方法进行冲刺规划。基于一系列过去的冲刺，速度估计通常会稳定，并为提高Scrum项目的短期和长期规划的准确性提供更可靠的基础。

注意：

速度是衡量团队在单个Sprint中可以解决的工作量的指标，也是Scrum的关键指标。通过将所有完全完成的用户故事的积分相加，在Sprint结束时计算速度。在计算速度时，不应计算部分完成或不完整故事的分数。

Step1 - 计算第一次迭代的速度（Sprint）

在每次迭代结束时，团队会将与在迭代期间完成的用户故事相关联的工作量估算值相加。这个总称为速度。

敏捷团队已开始进行迭代工作，计划完成故事A和B，估计分别为2分和故事C，估计为3分。在迭代结束时，故事A和B完成100％但C仅完成80％。敏捷团队通常只承认两个完成级别，0％完成或100％完成。因此，C不计入速度，并且该迭代的速度是4点。

第2步 - 使用Velocity估算所需的迭代次数

在了解步骤1中的速度之后，团队可以基于与剩余用户故事相关联的估计并且假设剩余迭代的速度将保持大致相同来计算（或修改）项目将完成多长时间的估计。这通常是准确的预测，即使很少是精确的预测。

假设剩下的用户故事总共代表40分; 团队对项目剩余工作量的预测是10次迭代。

Scrum中速度与故事点的关系

故事点用于衡量大小和复杂性，这意味着我们完成它需要多长时间。故事点是完成用户故事所需时间的相对度量。这是从XP借来的概念。它用于评估故事的难度，而不是承诺需要多长时间。这不管团队的规模或任务是什么，您都可以使用故事点。

如何将速度与故事点联系起来？

1. 团队通常需要使用“速度”作为衡量生产力的指标，以告诉外人确切的Scrum团队有多快。
2. 如果在整个项目中保持对故事点的估计，那么使用故事点来表示“速度”是有意义的。
3. 如果一致性不仅在团队中，而且在团队中，甚至在整个公司的层面上。这不仅可以衡量生产力，还可以比较每个团队的状态。
4. 如果故事点的值稳定，则可以将其用作发布计划的参考。您可以在之后评估可能的时间表。

如何确定用户故事的故事点？

故事点是一个相对测量单位，您的团队应该采取的第一步是将一个故事定义为基线，以便他们可以估计与该参考相比较的其他故事。根据文献，团队应该在积压中找到最简单的故事，并为其分配1个故事点，之后，他们使用该故事作为基线来估计其他故事。

有两种类型的比例用于创建用户故事点的估计：

• 线性刻度（1,2,3,4,5,6,7 …）
• 斐波那契序列号（0.5,1,2,3,5,8,13 …）

估计您的团队熟悉的第一个用户故事并且应该知道故事完成所需的时间是一个好主意。然后你估计你是下一个用户故事。如果您的团队认为它小于基线用户故事，那么您将其放在基线故事的左侧。然后你再次估计另一个用户故事。支持团队决定它也小于基线故事，但比第二个故事更大 - 所以你将第三个故事放在基线用户故事和第二个用户故事的中间。在这个例子中，我们使用Fibonacci序列号进行故事估计：

如何更准确地估算速度？

在Scrum中，velocity帮助您了解团队完成产品待办事项需要多长时间。然而，通常需要很少的冲刺才能让团队找到更稳定的速度。为了估计团队更准确的速度，我们可以根据团队过去的跟踪记录获得经验。它将更准确地预测团队在Sprint中可以执行的故事数量。出于预测目的，应使用最后三个或四个Sprint速度的平均值。

假设新的Scrum团队计划在他们的第一个sprint中完成41个故事点。他们最终只能完成38个故事点，并将6个故事点翻到下一个冲刺点。所以他们的速度是38，如下图所示：

基于过去的Sprint轨迹记录平均速度

如前所述，团队不应该为速度添加任何部分完成的工作。只有那些标记为“完成”的用户故事才算数，即使在任务中只剩下一小部分工作要做。

仅基于一个冲刺，速度不是用于进行预测的非常可靠的度量。（但它确实让团队了解他们在单个冲刺中可以承诺的工作量。）让我们跟踪他们进一步冲刺的进度。

现在，新的团队继续从Sprint 1 - 4开始随后的发展，他们第一次冲刺的故事点是第二次38,29，第三次38，第四次39。因此，4次短跑后的速度估计平均值为36，如下图所示：

这个平均值只有四次冲刺，比我们在一次冲刺后的快照更有用。很容易想象，如果积压已经估计的用户故事，我们可以使用此速度进行预测。我们可以预测团队完成所有工作的速度。我们可以对即将发布的版本中我们能够提供的功能进行有根据的猜测。

速度图表

如果Scrum团队完成了多次冲刺，团队可以通过查看速度报告来预测发布和产品完成日期，并更准确地规划未来的项目。根据报告所示的先前冲刺的速度，您可以实现以下目标：

• 跟踪您的团队报告的每个sprint完成的工作量。
• 如果您的团队组成和冲刺持续时间保持不变，请估计您的团队在未来冲刺中可以处理的积压工作量。

基于上面的示例，速度图显示了Scrum团队为完成的4个Sprint的每个sprint报告的完成工作量：