每个Sprint交付真正的增量：初学者友好解析

在Scrum中，增量是当前Sprint和所有先前Sprint中完成的所有工作的总和。每个Sprint必须产生至少一个增量，每个增量必须满足团队的完成定义。增量必须是可用的——它必须处于原则上可以发布给用户的状态——即使产品负责人决定不发布它。这一标准比许多团队意识到的更严格。功能完整但测试失败、有已知缺陷或文档不完整的增量不符合Scrum标准。本指南解释真正的增量是什么样子，以及如何持续产生一个。

真正的增量需要什么

• 反映产品质量标准的清晰完成定义，而非"开发完成"。完成定义应包括：代码审查、自动化测试通过、无已知缺陷、集成到主代码库、部署到预备环境、文档更新。如果一个条目已编码但未测试，则未完成。

• 对按完成定义能完成什么持现实态度的Sprint规划，而非对能编码什么持乐观态度。Sprint规划期间，团队应问：我们能在Sprint结束前完全完成这些条目中的每一个吗？

• 针对完成定义展示增量的Sprint评审，而非仅展示新代码的演示。如果条目未按完成定义完成，不应将其呈现为已完成——它们应返回产品Backlog。

团队常见的不足之处

• "完成"被定义为"编码完成"。当测试、集成和文档被视为Sprint后发生的独立活动时，每个Sprint末尾的增量实际上是从未被验证为有效的部分产品。

• 团队从完成定义中携带技术债务。当完成定义是有抱负而非强制执行时，条目积累测试债务、集成债务和文档债务。

• Sprint目标是功能列表而非成果。当Sprint目标是列表时，该列表的任何子集都算作部分胜利。当Sprint目标是成果时，要么实现，要么未实现。

XNM协助公共部门组织建立有效的敏捷交付实践。欢迎联系XNM项目群与项目交付咨询团队，获取在贵组织中建立严格Scrum实践的支持。