没有真正增量的冲刺只是一场状态汇报会
Scrum 给出一个简单的承诺：在每个冲刺结束时，团队都会产出一个可用的产品增量。不是一个半成品功能的演示，也不是一张写着「完成 90%」的幻灯片，而是一段符合「完成的定义」、可以发布的可运行产品。在经历了过去两年的动荡之后——团队分散在各自的家中办公、时间表被供应问题打乱——这个承诺变得更加重要，而不是更不重要。当没有人身处同一个房间时，真正的增量是干系人唯一可以信赖的诚实信号。
然而，增量恰恰是 Scrum 中被悄悄放弃得最多的部分。团队保留了各种仪式——每日站会、评审会、回顾会——但这些仪式本应守护的对象却渐渐流失了。下面说明的，正是配得上「增量」之名的增量，与只是假装是增量者之间的区别。
真正的增量是什么样子
一个健康的增量足够具体，产品负责人当场就能发布它。《Scrum 指南》对此毫不含糊：除非工作符合「完成的定义」，否则它不属于增量。其余的一切都是未完成的工作，而未完成的工作不是进度——它是你尚未偿付的风险。
它已集成进产品，而不是搁在某个旁支上，等待一次根本没人安排的合并。
它已按团队的「完成的定义」完成测试——不是「在我机器上能跑」，而是依据全体团队共同认可的标准得到验证。
它在以往增量的价值之上有所增益；产品仍作为一个整体运转，而不仅仅是新增的那一小块。
它能在冲刺评审会上作为可运行的软件被演示，无需任何「请想象这部分能用」之类的免责声明。
出席评审会的干系人能据此做出真实的决策，因为他们所见即所得。
团队转而接受了什么
当增量失守时，它几乎从不轰然崩塌。它是通过一连串听上去合情合理的小妥协被慢慢侵蚀的，而这些妥协累加起来，便造就了一个结束时拿不出任何可发布成果的冲刺。
顺延的习惯。 「基本上做完了，下个冲刺测一下就行。」测试本就是「完成」的一部分。总是落到下一个冲刺的工作，是永远没有真正完成的工作，而这一堆「快做完了」的事项，便悄悄成了项目的真实状态。
演示的表演。 评审会展示的是一个打磨过的原型或一段录制好的演示，而不是真正运行的产品。干系人为一件无法部署的东西鼓掌，认知与现实之间的鸿沟又拉宽了一个冲刺。
漂移的「完成的定义」。 在截止期限的压力下，「完成」悄悄少了一道工序——这里少了代码评审，那里少了无障碍检查。每一处删减都显得微不足道；合在一起却使增量不再可信，下一次发布也变成一场补做被推迟工作的混战。
集成的欠债。 每位开发者的工作单独都能通过，但各部分直到日后某个痛苦的「集成冲刺」才被拼到一起。远程团队尤其容易如此，因为当大家不是并肩而坐时，合并带来的摩擦很容易被一拖再拖。
解决之道不是逞英雄，而是对「完成的定义」保持诚实，并以纪律把标准守在团队设定的位置上。把工作切得足够小，让真正能完成的东西可以装进一个冲刺。持续集成，而不是拖到最后才合并。把冲刺评审会当作对真实产品的检视，而非一场表演——因为评审会一旦沦为表演，其余所有 Scrum 事件都会失去它们本应提供的信号。
如果你的冲刺一次次结束，却拿不出任何真正可以发布的东西，XNM 的项目群与项目交付咨询 可以帮助你收紧「完成的定义」，重建一个让干系人信赖的交付节奏。