每个冲刺都交付一个真正的增量：本周可用的清单
《Scrum 指南》说得直白：增量是迈向产品目标的一块具体踏脚石，且每个增量都必须可用。仅仅“快要完成”的工作不是增量。然而不少团队走到冲刺评审时，手里是一堆做了一半的事项、一场靠胶带勉强撑住的演示，以及没有任何真正可以发布的东西。原因通常是一份只存在于纸面、却未落到实践的“完成的定义”。
在分布式团队中，这会更难。当人们无法俯身到一张桌子前确认某样东西能运行，关于“完成”的含糊就会成倍增加。对策依然是 Scrum 一直要求的那份纪律，只是要更刻意地践行。下面是一份你本冲刺就能使用的清单。
冲刺之前与之中
确认你的“完成的定义”是明确且共享的；若质量标准只在某人脑中，请把它写在全团队都能看到的地方。
把冲刺待办事项拆分到每一项都能在本冲刺内合理地达到“完成”；无法在冲刺内完成的事项，无法成为增量的一部分。
在整个冲刺中持续集成与测试，而不是在最后一天疯狂赶工。
把“完成”当作一道门，而非可以擦边滑过的终点线；一个事项要么按你的定义算“完成”，要么就不算。
随做随让增量保持可用，使得在冲刺的任何时点都存在某个潜在可发布的东西。
在冲刺评审及其之后
演示能运行的软件，而非幻灯片。 冲刺评审是对照产品目标检视真实的增量。如果你展示的是意图而非运行中的功能，那增量就不是真实的。
不要把未完成的工作算进增量。 未达到“完成的定义”的事项要退回产品待办列表。把它们当作“基本完成”继续带着，会掩盖产品的真实状态。
即使选择不发布，也要让增量保持可发布。 是否发布是产品负责人的决定；增量必须处于这样一种状态：发布是一项业务选择，而非技术上的不可能。
随时间收紧“完成的定义”。 随着团队成熟，把更多质量检查并入“完成”。更强的定义产出更可信赖的增量，末尾所需的检视也更少。
借评审来调整产品待办列表。 与干系人一起检视一个真实的增量，应当改变你接下来要做什么。如果待办列表毫无变动，那场评审只是状态汇报，而非检视。
贯穿这一切的主线，是对工作状态的诚实。每个冲刺都交付一个虽小但确实“完成”的增量的团队，会建立起信任与稳定、可预测的节奏。而演示空气、暗藏债务的团队会同时侵蚀这两者。增量正是 Scrum 经验主义承诺落到实处之处：你检视真实的东西，并据此调整。
如果你最近几个冲刺都以手忙脚乱和一场摇摇欲坠的演示收场，那就从“完成的定义”入手。让它明确、让它共享，并拒绝把任何不符合它的东西称为“完成”。这份清单上的其他一切，都源自这一个决定。
如果你希望有人协助你建立一种每个冲刺都产出真实、可发布增量的交付节奏，XNM 的项目群与项目交付咨询 会与团队一道，让它真正落地生根。