处理Sprint中途中断：常见错误及如何避免

Scrum指南将Sprint描述为保护团队免受中断的容器——一个时间盒定义的时期，在此期间团队专注于在不受干扰的情况下交付Sprint目标。在实践中，大多数团队会经历中断：生产事故需要关注、高级利益相关者需要紧急报告、监管截止日期产生新要求。团队如何处理这些中断对交付绩效和团队士气都有重大影响。以下是团队在处理Sprint中途中断时犯的常见错误——以及如何避免它们。

错误1：不协商就接受中断

最常见的错误是将每个中断视为不可协商的，并立即将其添加到Sprint Backlog中。这侵蚀了Sprint目标，并向组织传达Scrum团队的承诺是可替换的。当中断到达时，产品负责人的角色是协商：这真的紧急吗？它能等到下一个Sprint吗？对中断的回答不应该总是"是"。

错误2：不跟踪计划外工作

不跟踪计划外工作的团队无法从中学习。如果团队在Sprint中途添加条目到Sprint Backlog而不将它们记录为计划外的，Sprint的速率数据将高估团队计划工作的容量。随着时间推移，团队将在Sprint规划时持续过度承诺，因为速率基准包括实际上被计划外工作消耗的容量。将每个Sprint中途添加跟踪为计划外的，并在Sprint评审和回顾中单独报告。

错误3：不解决中断的来源

• 有来自生产事故的反复中断的团队遭受着Sprint管理无法解决的系统性质量问题。如果20%的Sprint容量被生产支持消耗，团队和产品负责人应该讨论是否某些容量应该正式保留（不为新功能规划），以及技术债务减少是否属于Backlog。

• 有来自高级利益相关者的反复中断的团队遭受着沟通或治理问题。如果CEO可以以紧急请求中断任何Sprint，团队的Sprint承诺没有可信度。Scrum Master的角色包括与领导层合作建立和保护团队的边界。

• 有来自范围变更的反复中断的团队遭受着不清晰或不稳定的产品Backlog的困扰。如果条目在Sprint中途改变含义或优先级，因为需求没有被很好地理解，根本原因在Backlog细化中，而非Sprint管理中。

XNM协助公共部门组织实施Scrum并建立对组织中断具有弹性的团队实践。欢迎联系XNM项目群与项目交付咨询团队，探讨贵组织的Scrum团队有效性和敏捷交付。