在两次冲刺中，您团队的速率下降了 30%。该模式在图表中是明确无误的。利益相关者已经开始询问。总理正在看着你。你明天有计划。
这是工程管理中压力最大的时刻之一。它也是最常被误诊的疾病之一。
这是实际的剧本；首先要检查什么、七个真正原因（按概率顺序）以及什么 不 在压力下做。
第一：不要惊慌，不要责怪团队
在进行任何诊断之前，有两件事需要内化：
1-2 冲刺下降是噪音，而不是信号。 速率自然是有噪声的；疾病、假期、一张讨厌的罚单。如果你的上一个冲刺是 32 分，而前五个冲刺是 38-42，那么这就是方差，而不是趋势。不要反应。
3 次冲刺下降是信号。 如果连续三个冲刺比之前的基线低 25-30%，则表明某些情况发生了变化。调查。
现阶段最大的失败模式不是错误的诊断，而是错误的诊断。这是一位经理对噪音的反应，就像它是信号一样，并开始更加努力地推动。这就是如何将暂时的下降变成真正的下降。
它几乎从来不是
在列出真正的原因之前，先列出错误的原因。以下是管理者首先寻求的解释，但他们几乎总是错误的：
- “团队正在懈怠。” 不会。以 X 速率交付的工程师不会突然停止关心。工作或环境发生了变化，而不是他们的动机发生了变化。
- “他们需要更多纪律。” 不会。如果您的流程以 X 速率运行，那么它仍然在运行。增加仪式会使事情变得更糟。
- “他们需要踢一脚。” 不会。团队已经可以看到图表了。他们和你一样感受到压力。增加压力会使问题变得更加复杂。
如果您伸手去拿这些东西，请放慢速度。实际原因几乎总是结构性的。
七个真正原因（按概率排列）
1. 范围质量发生变化
这是第一大原因，但在图表中是不可见的。
看起来如何：工单比以前变得更大、更难或更模糊。团队拿起“5 点”工作，打开它，发现实际上是 13 点。他们完成了工作；但这不是同一个工作。该图表显示速率下降。事实上，点/工作校准发生了漂移。
查询方法：拉出最后5张“5分”票。阅读它们。它们与 8 个冲刺前的 5 点券大致相当吗？如果新的代码更加粗糙（更多的依赖项、更多的未知数、更多的遗留代码），你并没有放慢速度；而是你正在解决同样规模的更困难的问题。
解决方法：停止将最近的速率与旧的速率进行比较。重置基线。或者;更好的;修复范围。推动更清晰的工单、更小的故事、更少的冲刺计划中的未知因素。
2.人变了
有人离开了。有人加入了。现在有人在做 30% 的 PM 工作。有人休了 4 个冲刺的育儿假。
如何检查：拉动最近 3 个冲刺与前 5 个冲刺的团队能力。使用焦点因素而不是人数；一名高级工程师进行 70% 的面试并不是 1.0 能力，而是 0.3。
解决方法：如果是临时容量下降，请在计划中明确指出。 “本次冲刺我们的容量为 0.7，因此目标应该是 28 分，而不是 40 分。”不要假装团队已满负荷运转，而实际上并非如此。
3. 科技债务已跨过门槛
随着代码库老化，速率逐渐下降，有时当基础设施的关键部分开始崩溃时，速率会急剧下降。原本需要 8 分钟的测试套件现在需要 45 分钟。以前需要 5 分钟的部署现在需要 30 分钟。CI 不稳定。构建每天会中断两次。
如何检查：“琐碎”工单的周期时间（单行副本更改、版本升级等）。如果一张 1 积分工单现在需要 2 天才能交付，那么瓶颈不是工作；而是瓶颈。这是它周围的系统。
解决方法：将下一个冲刺的 20% 投入到特定瓶颈（测试速度、部署可靠性、构建不稳定）。这是可用的杠杆率最高的干预措施，也是应用最少的干预措施。如果团队无法在 4 小时内发送 1 分工单，那么问题就会变得更加复杂。
4. 依赖/外部阻碍
该团队的工作现在取决于另一个团队的工作。他们正在等待 API 访问、设计规范、安全审查、法律审查。工单进入“进行中”并坐在那里。
如何查看：统计“处理中”/“审核中”且 3 天以上没有变动的工单。阅读原因。如果“被其他团队阻止”多次出现，那就是原因。
修复：名称依赖 之前 冲刺计划，而不是冲刺期间。如果一张工单需要的设计在一周内不会存在，那么就不要在本次冲刺中进行计划。移动它。仅计划团队实际可以完成的工作。
5. 故事点通胀逆转
如果您的团队在多次冲刺中慷慨地调整了工单的大小（将 3 秒舍入到 5 秒，将 5 秒舍入到 8 秒），则速率图表会被人为夸大。当估计校准回到现实时；通常是在改进推动或新的技术主管加入之后；速率“下降”，但没有人减少工作量。
如何检查：询问团队最近的估算是否感觉更诚实，或者是否有新人加入来推翻夸大的估算。如果是，则下降是校准，而不是回归。
解决方法：向利益相关者解释。重置基线。将下一个冲刺与下一个冲刺进行比较，而不是与夸大的过去进行比较。
6.工作已经从功能转向重构/基础设施/发现
发布功能的团队会进入一个阶段，他们正在进行重大重写、基础设施迁移或预功能发现。这项工作是真实且必要的，但它并不完全符合“每个冲刺的故事点”。
如何检查：查看工单类型。如果上一个冲刺的 60% 是基础设施/重构/峰值工作，那么速率数字就会产生误导。该团队正在努力工作，只是从事规模更大的工作。
解决方案：将基础设施工作与功能速率分开跟踪。两个指标：特征点和“投资”时间。不要将它们混为一谈。
7. 流程漂移/新仪式
有人添加了新会议。有人添加了安全审查步骤。有人引入了更长的代码审查 SLA。每个个体的改变都很小。累积效应是真实的。
如何检查：列出上个季度的每个新流程变更。将每人的时间加起来。如果团队每人每周的实际编码时间减少 3 小时，您就会发现速率下降了 12%。
解决方法：质疑最近添加的每一个流程。它实际上捕获了什么以前没有捕获到的东西？捕获的鱼值得付出代价吗？
计划明天做什么
你早上有计划。图表看起来很糟糕。这是一次会议的剧本：
- 诚实地开放。 “在过去的 3 个冲刺中，速率有所下降。我希望我们根据实际容量进行计划，而不是旧的数字。我们将在回顾中进行正确的诊断；现在，让我们诚实地计划。”
- 使用最近的 3 个冲刺来设置容量，而不是滚动的 5 个冲刺。 如果最近的速率是 30，就计划 30。抵制“伸展”的诱惑。
- 缩小范围，不要填充估计。 如果你有 40 个“必备”点，但容量为 30，则减少 10 个必备点。不要试图低估它。
- 确定团队需要解决的一个结构性障碍。 测试速度、抚养税、工单清晰度；选择一个。为其预留20%的容量。这是杠杆，而不是原始努力。
这一次会议；诚实地持有；比任何“我们会赶上下一个冲刺”的承诺更能恢复信心。利益相关者更喜欢真实的数字，而不是理想的数字。
不该做什么
按造成损坏的大致顺序：
- 不要为了“提高知名度”而添加仪式。 更多的站立会议、更多的状态报告、更多的同步；所有这些都减少了可用于本已不足的工作的时间。
- 不要要求团队“更加努力”。 速率不是承诺的函数，而是实际能力和工作清晰度的函数。 “更加努力”听起来像是领导力；它像责备一样落地。
- 不要为了“让图表看起来更好”而重置故事点。 为了匹配历史速率而夸大估计是欺诈行为。这也使得未来的规划变得不可能。
- 不要衡量个人。 “爱丽丝的速率下降”是最糟糕的诊断。故事点是一个团队指标。
- 不要假设它是永久的。 大多数速率下降都有特定的原因，一旦找到，就有特定的修复方法。把它当作一个谜题，而不是一个判决。
衰退后的回顾
一旦你诚实地计划了下一个冲刺，就可以在下降时进行集中的回顾。格式：
- 发生了什么变化。 制定过去 12 周的时间表。离职、新加入者、流程变更、项目启动、基础设施事件。说出一切。
- 我们注意到了什么。 让每个人写下上个月最痛苦的一件事。先默读，然后讨论。
- 我们将改变什么。 选择一项结构修复。不是三个。一。运行 3 个冲刺，然后重新评估。
一支刚刚下降速率的团队是脆弱的。不要将更改堆放在上面。选择一个最能打动人心的修复，发布它，看看有什么变化。
诚实的总结
每个团队都会发生速率下降的情况。它们很少与努力有关，几乎总是与范围、容量或系统健康状况有关。冷静诊断，诚实计划，从结构上解决一件事，抵制施加压力的冲动。
那些快速恢复的球队并不是那些在低谷后最努力的球队；他们清楚地指出了原因，并在不加任何仪式的情况下解决了这个问题。这就是领导层此刻的实际工作。
速率是反馈信号。当信号移动时，它在告诉你一些事情。倾听它而不是试图让它安静下来。
有帮助的工具：
- 冲刺速率计算器：跟踪过去 5 个冲刺的速率，免费，无需注册。
- 冲刺能力计算器：使用焦点系数设置实际容量。
- 冲刺 成熟度评估：快速诊断目标命中率、范围蔓延、阻碍因素、追溯行动跟进。
- 冲刺 成熟度自我评估：跨越 6 个维度的 10 个问题，每层有 3 个具体的下一个冲刺行动。
相关阅读：
- 敏捷估算技术比较：如果速率下降隐藏了估计校准漂移，这是五种真实技术的并排以及如何在不消耗冲刺的情况下进行切换。
SprintFlint 自动显示速率、周期时间和目标命中率趋势。当图表发生变化时，您会先于利益相关者明白原因。 每月50张免费工单: 没有卡。