如何写出真正能定纷止争的验收标准
用户故事只是一次对话的起点，而验收标准正是把这次对话钉死下来的地方。它们说明产品待办列表项在被认定为完成之前必须满足哪些条件。没有它们，“完成”就会漂移：开发者以为功能可用，产品负责人却期待着另一回事，分歧在 Sprint 评审会上爆发——而那正是修复代价最高的时刻。
在经历了长时间的远程办公之后，分布式和混合办公的团队已成常态，你再也无法靠走廊里的一次随口交谈来消除歧义。故事及其标准必须独自承载全部含义。把它们写好，是团队能做的最划算的质量投资之一。
好的验收标准是什么样子
验收标准既不是设计文档，也不是测试脚本。它们从用户的视角描述可观察的结果，而非实现方式。它们也不等同于完成的定义，这一点最好及早厘清：完成的定义是适用于每一个产品待办列表项的共同标准，而验收标准只针对某一个故事。把两者混为一谈，要么让每个故事都堆满千篇一律的套话，要么悄悄放松了质量门槛。一组好的标准应当是：
可检验——能够明确判定通过或失败，无需主观裁量
以结果为中心——用户现在能做什么，而非代码如何实现
彼此独立——每条标准都能单独成立
不含解决方案细节——把“怎么做”留给开发者
数量精简——三到七条，而非一份规格说明
一种易读且常用的格式是“假如—当—那么”：假如处于某种情境，当某个动作发生时，那么便产生某个具体结果。这并非强制——一份普通的检查清单同样可行——但它能迫使你明确写出前置条件、触发动作和预期结果。
一套实用的撰写方法
从用户的目标出发。 在列出任何条件之前，先复述这个人想要达成什么。如果你说不出目标，这个故事就还没准备好。
先写顺利路径。 先写出正常且成功情形下的标准。这是大家都认同的主干。
再补上真正重要的边界情形。 空输入、允许的最大值、过期的会话、失败的支付。只纳入会改变行为的边界情形，而非所有理论上的情形。
让每条标准都可验证。 把“快”、“好用”或“安全”换成能够检查的东西：一个数字、一个可见状态、一条具体消息。
与整个团队确认，而不只是产品负责人。 开发者和测试人员会在工作开始前发现遗漏的情形和隐藏的假设。
把它们与完成的定义区分开。 标准只属于这个故事；完成的定义适用于每一项，涵盖诸如测试通过、代码已评审等内容。
应当避免的常见错误
有三个陷阱反复出现。第一个是把设计偷偷塞进去——“加一个下拉菜单”是解决方案，而“用户可以从已批准的地区中选择”才是结果。第二个是标准含糊到根本不可能失败，比如“运行正常”。第三个是任由清单膨胀成二十条的微型规格说明；这说明这个故事本应拆分。还有一种更隐蔽的失误：标准写好一次便再也不去回顾，哪怕 Sprint 期间的交流已经改变了团队所掌握的情况。在这一项完成之前，都应把它们当作会变化的东西来对待。
当验收标准清晰时，Sprint 评审会便不再是一场谈判，而成为一次演示，团队的预测也会更稳定，因为每个人估算的都是同一件事。它们还让把一个大故事拆成若干各自具备价值的小切片变得容易得多，因为标准会显出天然的拆分线。开工前在它们身上花十分钟，往往能省下数小时的返工以及随之而来的摩擦。
如果你们的故事在评审时仍不断引发“我要的不是这个”的争论，XNM 的项目群与项目交付咨询可以帮助你的团队写出经得起推敲的标准，并收紧从待办列表到可用软件的路径。