理解Sprint速度：现实的现场指南

在Scrum中，速度是团队在Sprint中完成的工作量，以用于调整产品待办列表项的单位（故事点、小时或项目）衡量。它用于预测完成一组待办列表项需要多少个Sprint，并为Sprint规划的容量规划提供信息。速度是描述性的——它描述团队所做的事情——应该用作预测工具，而非绩效目标。

速度在实践中的样子

完成了四个Sprint速度分别为32、38、41和35故事点的团队平均速度约为36-37故事点。范围（32到41）是正常且预期的——Sprint间速度变化是规律，而非例外。每个Sprint都完成完全相同速度的团队几乎肯定是在调整其待办列表以匹配目标，而非诚实地预测。Sprint间速度变化的正常原因包括：团队成员缺席、计划外支持工作或事件、故事点估算差异，以及需要不同类型工作的Sprint目标。

场景1：项目中期速度下降

一个政府系统现代化项目的Scrum团队在连续两个Sprint中经历了速度从平均42故事点下降到平均28故事点。Scrum Master调查发现两个原因：(1) 团队在高峰服务期间被分配了遗留系统的额外支持职责，消耗了约30%的Sprint容量；(2) 团队五名开发人员中的两名被拉入另一个项目的架构评审。两个原因都是暂时的且可解决的。Scrum Master将两者都升级给产品负责人和管理层，支持职责被重新分配，速度在两个Sprint内恢复到之前的范围。

场景2：速度被用作绩效目标

管理层告知开发团队其速度需要增加20%以满足项目截止日期。团队通过膨胀故事点估算来响应——之前调整为3或5点的项目现在调整为5或8点。报告速度增加了，但实际生产力没有增加。规划预测变得不可靠，因为团队的历史速度不再与当前速度可比。截止日期没有实现。教训：速度是预测的校准工具，而非绩效指标。对团队施压以提高速度会产生游戏，而非改进。

场景3：稳定速度实现可靠预测

一个长期运行基础设施项目的成熟Scrum团队在八个Sprint中保持了相对稳定的每Sprint 45-55故事点的速度。使用这个历史速度，产品负责人能够以合理的信心预测剩余产品待办列表（估计约380故事点）将在约七到九个Sprint中完成——为利益相关者提供项目完成的可靠规划视野。

XNM为公共部门组织提供Scrum辅导和敏捷交付顾问服务。欢迎联系XNM项目群与项目交付咨询团队，探讨贵组织的Scrum指标和敏捷预测。