用户故事只写了“谁要什么”，没写“怎样算做到”，开发按理解实现、测试按经验验收，返工和争议往往在提测后才暴露。本文按“界定缺失范围—核查原因—分批补齐—验证防复发”的顺序给出处置路径，帮助团队把验收条件变成故事进入开发的准入项。
要点总览（TL;DR）
- 用户故事缺少验收条件，先盘点缺失形态：完全缺失、只写正常路径、写成任务清单，并把需求本身不清楚的故事转回需求澄清。
- 原因排查围绕模板栏位、评审检查点、标准散落在用例与口头沟通、变更后未同步四条假设，用模板配置、评审纪要、用例对应关系和变更历史逐条证实或排除。
- 补齐按优先级分批：本迭代待开发待测试的故事先补，每条覆盖正常路径可观察结果、边界与异常、数据与权限约束，用“给定—当—则”一条只验证一个结果。
- 验证看下游能否独立使用：测试仅凭故事与验收条件即可设计用例，评审中关于完成标准的追问明显减少。
- 把验收条件设为故事进入开发的准入检查项，需求变更时同步更新并留痕，用返工次数、验收争议和用例对应覆盖率跟踪效果。
先确认缺的是哪一类验收条件
“缺少验收条件”是一个笼统说法，实际包含几种不同形态，处置方式也不同。第一步不是急着补写，而是抽样盘点，把问题范围界定清楚，避免把需求本身的模糊也混进验收条件问题里。
建议从当前迭代和下一个迭代的故事清单中抽样，逐条标记验收条件状态，分为三档：完全没有；只有正常路径描述；包含正常路径、边界异常和数据权限约束。三档对应的工作量差别很大，只有正常路径的故事往往只需补充边界，完全缺失的故事则需要重新对齐完成标准。
盘点时同步做一项区分：这条故事是“验收条件缺失”，还是“需求本身不清楚”。判断方法很直接——如果团队对“要做成什么样”没有分歧，只是没写下来，属于验收条件缺失；如果对业务规则、范围、优先级本身就有不同理解，那属于需求澄清，应先回到需求分析环节，补验收条件解决不了这类问题。
盘点表可按故事类型分组统计，例如新功能、存量改造、后台配置类。经验上，后台配置和改造类故事最容易只写操作步骤而漏掉结果校验，新功能故事则容易只覆盖主流程。统计出缺失集中在哪类故事，后续补齐的优先级和模板调整就有了依据。
| 缺失形态 | 典型表现 | 处置方向 |
|---|---|---|
| 完全缺失 | 故事只有角色、目标、价值三句话 | 与产品、测试对齐后整条补写 |
| 仅正常路径 | 只描述顺利完成的场景 | 补充边界、异常、权限条件 |
| 写成任务清单 | 罗列“开发登录页、接口联调”等动作 | 改写为可观察的结果描述 |
| 需求本身不清楚 | 对业务规则存在分歧 | 转需求澄清，暂不计入验收条件缺失 |
缺失的常见原因与排除证据
盘点出范围后，下一步是判断为什么会缺。原因不能靠感觉下结论，每个假设都要找到可核查的证据，标记为已证实、已排除或待观察，再决定从哪一环下手整改。
假设一：故事模板没有验收条件栏位
如果团队使用的故事模板只有“作为……我希望……以便……”三段式，没有验收条件字段，写的人自然容易略过。核查方式是查看需求管理工具或文档模板的实际字段配置，以及近期故事的填写完整度。若模板确实缺栏位，且多数故事在该位置为空，可判定为已证实。
假设二：评审只确认故事可读，不检查可验证性
评审会上大家确认“这个故事看懂了”，却没人问“测试怎么判断它做完了”。核查方式是翻看近几次需求评审的记录或纪要，看是否出现过对完成标准的追问、是否形成结论。若评审记录中从未涉及验收口径，且评审通过的故事仍有大量缺验收条件，该假设成立。
假设三：验收条件写在测试用例或口头沟通中
有些团队的验收标准实际存在，只是散落在测试用例、聊天记录或口头约定里，没有回填到故事上。核查方式是抽取若干故事，查找其对应的测试用例和沟通记录，看能否还原出完整标准。若能还原但故事本身为空，说明问题在信息归位而非标准缺失，处置成本较低。
假设四：需求变更后验收条件未同步更新
故事最初有验收条件，但需求调整后只改了描述、没改条件，导致条件与实际行为脱节。核查方式是比对故事的变更历史与验收条件的最后修改时间，若存在描述已改而条件未动的情况，可证实该原因。
| 原因假设 | 可查证据 | 判定结论 |
|---|---|---|
| 模板缺栏位 | 模板字段配置、故事填写完整度 | 已证实／已排除／待观察 |
| 评审无验证检查点 | 评审纪要、追问记录 | 已证实／已排除／待观察 |
| 标准散落在用例与口头沟通 | 用例与故事的对应关系 | 已证实／已排除／待观察 |
| 变更后未同步 | 故事变更历史与条件修改时间 | 已证实／已排除／待观察 |
四个假设可能同时成立，排查时按证据获取成本从低到高进行：先看模板和评审记录，再查用例对应关系，最后比对变更历史。结论写进对照表，作为后续整改措施的选择依据。
按故事补齐验收条件的处置步骤
补齐工作要有顺序，避免一次性重写全部历史需求。优先处理即将进入开发或测试的故事，历史故事按迭代分批回补，每批控制在团队可评审的范围内。
每条故事补三类条件。第一类是正常路径的可观察结果，描述用户完成操作后系统呈现什么状态、产生什么数据；第二类是边界与异常，包括输入极值、空值、重复提交、依赖服务失败等场景下的预期表现；第三类是数据与权限约束，说明不同角色能看到什么、能改什么，以及数据状态如何流转。
表达上采用“给定—当—则”结构或检查项形式，一条条件只验证一个结果。例如：“给定用户已登录且购物车有商品，当用户提交订单且库存充足，则订单状态变为待支付并扣减对应库存。”条件写得越具体，测试越能直接据此设计用例。
补齐前先与产品、开发、测试对齐口径，明确由谁主笔、谁确认，避免三方各写一套。对于已上线功能的改动，先备份原需求描述与对应用例，再替换验收条件，保留可回溯的版本，防止补齐过程覆盖掉仍在使用的旧标准。
- 第一批：本迭代待开发、待测试的故事，逐条补齐并当天评审确认。
- 第二批：下个迭代已排期的故事，在排期会上同步补齐。
- 第三批：历史存量故事，按模块或迭代分批回补，优先覆盖高频变更区域。
当故事数量较多、验收条件需要与评审记录和变更历史对应时，可以在需求管理工作项中为故事增加验收条件字段，把条件、评审结论和变更记录放在同一条工作项下。ONES 的需求管理工作项支持自定义字段与状态流转，评审意见和变更留痕可随故事一并保存，便于补齐时核对原始口径，也方便后续抽查时快速定位每条故事的验收条件版本。
验证补齐效果与防止再次缺失
补齐是否有效，不看补了多少条，而看下游能否独立使用。最直接的验证方式是让测试仅凭故事和验收条件设计用例，如果过程中不再需要反复找产品确认完成标准，说明条件已经足够可验证。评审会上也可以观察：关于“怎样算做完”的追问是否明显减少。
抽查下一迭代的故事，统计带验收条件的比例，作为过程指标跟踪。比例稳定在高位，说明写法习惯已经建立；出现回落，则要回到原因对照表，看是哪一环松动。
防复发的关键是把验收条件设为故事进入开发的准入检查项。评审清单中增加一条“验收条件是否可验证”，未通过的故事不进入开发排期。需求发生变更时，同步更新验收条件，并在变更记录中留痕，避免出现描述已改、条件未动的情况。
效果可以用几个指标观察：因完成标准不清导致的返工次数、验收阶段的争议数量、测试用例与故事的对应覆盖率。这些指标不需要复杂统计，按迭代记录即可看出趋势。准入规则草案应写明检查项、责任人和未通过时的处理方式，先在一个团队试行，再根据实际执行情况调整。
常见问题
故事只写了正常路径，算不算缺少验收条件？
算，但属于部分缺失，处置成本低于完全缺失的故事。这类故事通常已经写清了主流程的预期结果，缺的是边界、异常和数据权限约束，例如输入极值、空值、重复提交、依赖服务失败，以及不同角色能看到什么、能改什么。
补齐时保留原有正常路径描述，在其后追加边界与权限条件即可，不必整条重写。盘点阶段把这类故事单独归为一档，可以避免和完全缺失的故事混在一起估算工作量。
验收条件和测试用例有什么区别，两边都要写吗？
验收条件描述业务上“怎样算做到”，用业务语言写，供产品、开发、测试共同确认完成标准；测试用例描述具体怎么验证，包含操作步骤、测试数据和预期结果，由测试人员设计。
两者都需要，但顺序是先有验收条件、再有用例。验收条件写在故事上，用例从验收条件推导而来。如果团队发现标准只存在于用例中，说明信息没有归位到故事，补齐动作是把用例中已隐含的标准回填到故事，而不是重新发明一套。
历史存量故事很多，全部补完不现实，怎么取舍？
按变更频率和后续开发计划取舍，不必追求全覆盖。优先补即将进入开发或测试的故事；其次是下个迭代已排期的故事，在排期会上同步补齐；历史存量按模块或迭代分批回补，优先覆盖高频变更区域。
长期不再改动、且已有稳定用例覆盖的老功能，可以只登记状态、暂不补写。判断标准是这条故事后续是否还会被修改或复用，会则补，不会则记录在案即可。
需求变更频繁，验收条件刚补完又过时了，怎么处理？
把验收条件与需求描述绑定为同一次变更的一部分：改描述时必须同步检查验收条件，并在变更记录中留痕，写明改了哪条条件、为什么改。这样即使变更频繁，也能通过变更历史还原每条故事当时的验收口径。
如果团队使用需求管理工作项，可以把验收条件作为工作项字段，与描述、评审意见放在同一条记录下，变更时一并更新，抽查时按版本核对。变更频率特别高的模块，可以在评审清单中增加一条“变更后条件是否同步”的检查。
准入检查会不会拖慢排期，团队抵触怎么办？
先在一个团队或一个迭代试行，把检查项限定为一条“验收条件是否可验证”，由评审主持人确认，未通过的故事退回补充而不直接排期。试行期记录因退回造成的延迟和因标准不清造成的返工，用两组数据对比说明收益。
如果抵触主要来自补写工作量，可以先只要求新故事和变更故事满足准入，存量故事按批次回补，降低一次性压力。规则稳定后再逐步扩大适用范围。
