人人都批准、却没人能验收的那个故事
在冲刺规划期间，一个 Scrum 团队拿进了一个故事，内容只是：「用户可以重置密码。」大家都点了头。产品负责人很满意，开发人员做了估算，它就进了冲刺待办列表。三天后它「完成」了——随即引发争议。产品负责人期望的是一封带有效期的邮件链接；而开发人员做的是一套安全问题流程。对那句含糊的话来说，两种理解都说得通。这是一个匿名化但极为常见的情形，而根本原因几乎总是同一个：这个条目没有验收标准。
验收标准到底是什么
验收标准是产品待办列表项必须满足、以便产品负责人认定其完成的那些具体且可测试的条件。它们不是「完成的定义」——《Scrum 指南》把「完成的定义」描述为适用于每一个增量的共同质量标准（测试通过、代码经过评审、可部署）。验收标准则专属于某一个条目：它们描述这个故事具体必须做到什么。一个团队两者都需要。「完成」是每个条目都要越过的那道横杆；验收标准则让你知道这个条目是否做对了事情。
用验收标准重写这个密码故事，一切都变了样：
假定一个已注册用户请求重置，当他提交自己的邮箱时，那么一封重置链接会发送到该地址。
重置链接在签发后 30 分钟过期。
已过期或已使用过的链接会显示清晰的提示，并提供重新发送。
成功重置后，用户原先的密码不再可用。
如今在冲刺结束时已无可争论。那场原本会围绕一个已完成版本展开的紧张争执，转而在梳理阶段、以极低的成本、在写下一行代码之前就发生了。
让验收标准保持有用的习惯
在条目可进入冲刺之前就写好它们。 验收标准属于产品待办列表梳理，而不属于演示。没有验收标准的故事还不具备被规划的条件。
让每一条标准都可测试。 如果你想象不出能证明它真伪的那项检查，那它就是一个愿望，而非标准。「快」是愿望；「在两秒内响应」才是标准。
聚焦结果，而非实现方式。 陈述用户必须能够做到什么，把如何实现的空间留给开发人员。标准约束的是结果，而不是设计。
保持这组标准的精简。 三到六条犀利的条件，胜过十五条含糊的。如果一个故事需要十几条标准，那它很可能是两个故事。
为什么这在分布式团队里更重要
当大家同处一室时，一个只定义了一半的故事，靠着隔着桌子快速地问几句澄清，也能勉强过关。当团队远程工作时，这条非正式的修补渠道更弱、也更慢。书面、可测试的验收标准，承载着过去由走廊对话所传递的共同理解。它们不是官僚主义——它们是 Scrum 团队所能拥有的、防止把错的东西做对的最廉价的保险。
如果你的团队总是完成了却偏离本意的工作，XNM 的项目群与项目交付咨询 可以帮助你收紧定义与验收工作的方式。