定义：

在决定敏捷项目的进度时，速度是一个非常重要的度量标准。它起源于物理学中的时间和距离理论，用来衡量团队在特定的时间间隔内完成了多少工作（故事点）。间隔通常选择为Sprint或迭代持续时间，单位：为完成故事的数量。

注意：

  1. 如果在迭代内，有未完成的用户故事，哪怕只完成50%的故事点，都不能算进入这次迭代内。
  2. 速度反映了团队的迭代的能力，注意，速度不能用来作为绩效，或者跟其他团队比较，这样毫无意义。因为每个团队能力不一样。
  3. 初始速率可以通过三种方法获得初始速度：
    • 基于历史数据
    • 运行几个（2~3次）迭代，使用那几轮迭代的平均速率
    • 专家判断（专家预测）

前几次迭代的速度

团队在5次迭代中，实际完成的故事点：
image.png

统计团队的平均速度

  • 每个Sprint的速率，求出完成故事点的评估值，这个平均的故事点数，被称为速度
  • 如果知道团队速率，那么就可以推算一个发布需要多少个迭代。一个发布总故事点 / 团队的速率 = 需要的迭代次数
  • 5次迭代的平均值：16sp

image.png

每个迭代实际完成故事点与理想故事点的比较

image.png
绘制团队的实际速度图可以很好地了解团队的能力和表现。
理想情况下，红色的趋势线应该有一个向上的梯度，表明团队随着时间的推移工作得更有效率。然而，急剧的增长可能表明在故事的估计方面存在问题，团队由于超时而超额完成，或者进度的跟踪不是统一的。
速度趋势的下降，可能表明一些问题：

  • 该团队发现了一些在评估过程中没有预料到的复杂性、风险。
  • 团队中出现了人员流失，或者有新成员加入。
  • 一名或多名团队成员因休假或培训等非项目活动而缺席，无法完成计划的工作。

测量团队初始速度

  1. 基于历史数据：如果项目基于技术、领域、环境和团队组成与以前的项目相似，那么历史数据可以用来预测当前团队的速度。然而，为了安全起见，最好是用一个范围来表示速度，而不是用一个绝对数字。
  2. 通过运行几个迭代：如果可以启动一个项目，最好运行2-3个迭代，并根据观察到的团队动态的速度来预测速度。
  3. 基于专家判断或假设的推断：在缺乏历史数据或无法进行几次迭代的情况下，必须依靠基于专家判断的推断速度估计。这通常是通过随机选择故事，将它们划分为任务，评估它们，并将它们放入迭代中来实现的。通过总结适合这个假设迭代的故事点，可以预测团队的速度。最后，这些估算应表示在一个范围内，以满足数字的不确定性。

基于团队速度，选择下个迭代的用户故事

假如团队的速度是24sp

  • 场景1：先选PB1、PB2、PB3，这三个刚好等于24 | Items from the backlog | PBI 1 | PBI 2 | PBI 3 | PBI 4 | PBI 5 | PBI 6 | PBI 7 | | —- | —- | —- | —- | —- | —- | —- | —- | | Priority ranking | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | Story point estimate | 13 | 8 | 3 | 2 | 1 | 5 | 8 |

  • 场景2：先选PB1、PB2、此时还剩下3点就不能容纳PB3，因此跳过PB3，继续选PB4和PB5，这样四个合计24 | Items from the backlog | PBI 1 | PBI 2 | PBI 3 | PBI 4 | PBI 5 | PBI 6 | PBI 7 | | —- | —- | —- | —- | —- | —- | —- | —- | | Priority ranking | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | Story point estimate | 13 | 8 | 8 | 2 | 1 | 5 | 8 |

  • 场景3：续上表，需要多少个迭代完成：13+8+8+2+1+5+8=45。45/24取整等于2，因此需要2个迭代才能完成。

  • 场景4：因为PBI的故事点是8sp，条件允许，可以将PBI 3再分解为几个小的故事，然后与PBI 1和PBI 2凑够24。

提升团队速度的办法

  • 持续关注代码重构，从而消除技术债务的所有痕迹。任何不使用的代码都必须删除。简单而灵活的设计和代码总是容易评估和处理的。
  • 激励员工尽其所能，让他们本能地、创造性地思考。允许团队邀功并保持成就感。
  • 确保团队成员集中精力，避免分心。
  • 与客户接触并征求他的意见，以澄清需求，征求意见，或经常寻求反馈。
  • 引入更多的人来分担工作，尽管这会增加成本。可能需要很短的时间来培训和让新工匠上岗，但经过一段时间，他/她的生产力将会提高。

必须再强调！

  1. 两个团队的速度是无法比较的。如果团队A速度是20，团队B速度是30，这并不意味团队B更高效。这是因为速度是基于不同团队对基准故事点的定义
  2. 计算迭代速率不应包含未完成的故事（即未达DoD)。在一个Sprint中，团队完成了估算值为5、7、2的用户故事，另外2个用户故事，只完成部分，迭代结束时速度将是5 + 7 + 2 = 14。未完成的工作代表沉没成本，对客户来说没有有形价值，
  3. 速度有助于消除估算中的不准确性。即使估算不是准确的，通过跟踪在几个迭代中实现的实际速度的趋势，团队速度在预测上变得更好。
  4. 速度不是生产力的衡量标准。不应该被用作团队成员绩效评估的标准。
  5. 由于团队的速度是用于预测（例如，完成n个故事点需要多少次迭代)，团队应该考虑乐观或最佳情况（当速度最快时）和悲观或最坏情况（当团队速度最低时）。为了评估完成项目的估算，应该区分预测的速度和实际的速度。
  6. 随着团队的成熟，获得更多的经验和对领域、技术和客户需求的控制，团队的开发速度预计会随着时间的推移而增加。一个有经验的团队习惯于相互协调地工作，利用协同作用并不断改进其工作方式。