了解冲刺速率
如果有人问你“什么时候完成?”并努力给出自信的答案,你并不孤单。冲刺速率是最强大的工具之一,你必须用数据而不是猜测来回答它。
速率到底是什么?
速率是团队在冲刺中完成的工作量,以 故事点.
就是这样。没有魔法,没有复杂性。它是一个跟踪指标,告诉您团队历史上交付了多少,这成为预测未来绩效的基础。
将速率想象成您的平均行驶速率。如果您通常在高速公路上以 60 英里/小时的速率行驶,您可以合理地估计 300 英里的行程大约需要 5 小时。你不会因为自己乐观而承诺在 3 小时内完成,也不会因为交通偶尔减慢你的速率而责备自己。速率的工作原理相同;这是基于现实的基线,而不是野心。
为什么速率很重要
速度的可预测性
利益相关者不仅想要快速交付,还想要快速交付。他们想要 可预测的 交货。每个冲刺持续交付 40 个故事点的团队比一个冲刺交付 60 个故事点、下一个冲刺交付 20 个故事点、之后的冲刺交付 45 个故事点的团队更有价值。
当您知道自己的速率时,您可以:
- 预测发布日期 具有置信区间(“我们可能会在 6-8 次冲刺中交付”)
- 推迟不切实际的最后期限 数据(“我们的速率表明这是 12 个冲刺的承诺,而不是 6 个”)
- 及早发现问题 当速率意外下降时
建立利益相关者的信任
没有什么比错过承诺更快地侵蚀信任。当您根据实际速率始终低于承诺并超额交付时,利益相关者就会学会相信您的估计。这种信任意味着更少的微观管理、更少的紧急会议以及更多的团队自主权。
更明智的规划
速率可以帮助您避免计划谬误:我们低估事情需要多长时间的认知偏差。通过将冲刺计划建立在历史表现而不是乐观的基础上,您可以让您的团队取得可持续的成功。
如何计算速率
基本公式
速率 = 在冲刺中完成的故事点的总和
“完成”的故事符合您团队的需求 完成的定义:已编码、测试、审查并可能可交付。 部分完成的工作算作零。
计算平均速率
大多数团队使用最后 3-6 个冲刺的滚动平均值:
平均速率 =(最后 N 个冲刺的故事点总和)/N
计算示例
这是超过六个冲刺的团队的真实速率计算。要在没有电子表格的情况下对您自己的冲刺历史运行相同的数学运算,请尝试 免费速率计算器.
| 冲刺 | 故事点已完成 | 注释 |
|---|---|---|
| 冲刺1 | 38 | 新团队成员加入 |
| 冲刺2 | 42 | 标准冲刺 |
| 冲刺3 | 35 | 两名开发商生病了 |
| 冲刺4 | 44 | 冲刺强劲,干扰少 |
| 冲刺5 | 40 | 标准冲刺 |
| 冲刺6 | 39 | 标准冲刺 |
| 平均 | 39.7 | 四舍五入到 40 进行规划 |
对于 冲刺 7 规划,该团队应承诺大约 40个故事点。不是 50 岁,因为他们“想要做得更好”。不是30,因为他们很谨慎。 四十,因为数据就是这么说的。
使用 Velocity 进行发布计划
如果您的待办列表工作还剩 240 个故事点,并且您的速率为 40:
所需冲刺 = 240 / 40 = 6次冲刺
对于 2 周的冲刺,大约需要 12 周(3 个月)才能完成。
专业提示: 始终添加缓冲区。使用速率范围而不是单个数字。如果您的速率范围为 35-45,请告知发布将需要 5.5-7 个冲刺(11-14 周)。
常见的速率错误
1. 团队比较
切勿比较团队之间的速率。 A 队的“8 分”与 B 队的“8 分”不同。故事点是仅在单个团队内有意义的相对估计。
2. 忽略异常值
那个冲刺你只完成了 15 分,因为一半的团队都感染了流感?或者是在 70 分的冲刺中你还清了一年的技术债务?这些异常值可能会扭曲您的平均值。如果您的速率变化很大,请考虑排除它们或使用中位数而不是平均值。
3. 不根据假期和 PTO 进行调整
如果整个团队的平均速率为 40,则不要指望假期期间会达到 40。按比例调整期望:
调整速率=正常速率×(可用团队容量/满容量)
8 名开发人员中有 3 名出局:40 × (5/8) = 25 个故事点
4. 将速率作为目标
速率是一种测量,而不是目标。 当团队被迫“提高速率”时,他们就会玩弄系统:夸大估计、偷工减料,或者把故事当作“快完成了”。
5. 包括未完成的工作
就速率而言,完成 90% 的故事就是完成了 0%。在按照您对完成的定义完全完成之前,它不算数。没有部分信用。这条规则看似严厉,但它使指标保持诚实。
提高速率(正确的方法)
如果速率不是要更加努力地工作,那么如何提高速率呢?
删除阻碍
提高速率的最快方法是消除拖慢团队速率的因素:
- 长代码审查? 实施配对或更小的 PR
- 生产火灾频繁发生? 投资于监控和稳定性
- 要求不明确? 花更多时间精炼
- 外部依赖? 尽早识别并升级阻止者
减少上下文切换
没有什么比持续的干扰更能降低速率了。保护团队的专注时间:
- 将会议分批分配到特定日期
- 尽可能使用异步通信
- 在冲刺期间保护团队免受非紧急请求的影响
解决技术债务
六个月前的“快速修复”现在正在减慢涉及该代码的每个功能。随着时间的推移,专门的重构时间会带来速率红利。请参阅 技术债务术语表条目 了解如何确定规模并支付费用。
调整故事的大小
太大的故事(超过 13 点)会产生不确定性,并且经常会在冲刺之间滚动。故事太小(1 分)会产生开销。目标是与大多数故事进行健康组合,得分在 3-8 分范围内。
SprintFlint 中的速率
在电子表格中手动跟踪速率适用于小型团队,但它很快就会变得乏味且容易出错。 SprintFlint 的速率仪表板承担着繁重的任务:
- 自动计算 从已完成的工作
- 趋势可视化 随着时间的推移
- 异常值检测 和异常突出显示
- 容量调整预测 基于团队的可用性
开始你的第一次冲刺 →
底线
速率并不是要最大化的分数;而是要最大化的分数。它是了解团队能力的一个镜头。如果使用得当,它可以将评估从艺术转变为科学,通过一致的交付建立利益相关者的信任,并帮助您在系统性问题演变为危机之前识别它们。
记住: 开始诚实地测量它。一致地计算它。最重要的是,用它来更好地讨论现实问题,而不是让你的团队更加努力。
最好的工程团队并不是速率最快的团队。他们的速率值得您信赖。