用户故事缺少验收条件，通常不是单个故事写漏了，而是需求表示环节缺少位置、标准和检查点。本文按“先确认缺失范围、再验证原因、逐条补齐、最后验证并防复发”四步展开，帮助团队判断问题出在模板、评审、职责还是写法能力，并把验收条件补到可评审、可验证的程度。
要点总览（TL;DR）
- 先抽样确认缺失范围：按迭代、模块、需求来源分层抽取不少于二十个故事，把完全缺失、模糊描述、与功能重复三种形态分开统计，判断是系统性缺失还是个别遗漏。
- 原因排查按模板、评审、职责、能力四步走，每条假设都要有可回看的证据，多条原因同时成立时需一并处理，只改模板不改评审容易复发。
- 补齐时以场景或业务规则为线索，覆盖正常路径、边界条件与异常处理，条目要可观察、可判定，并由需求提出方、开发、测试共同确认。
- 无法立即补齐的故事设停止点，暂不进入开发，先澄清需求内容，避免带着空白验收条件开工。
- 防复发靠模板必填、评审通过条件、定期复查三个检查点，复查指标固定为缺失比例、模糊描述占比和待澄清条目平均关闭时长。
先确认缺失范围：哪些用户故事没有验收条件
排查从抽样开始，先回答“缺多少、缺在哪、缺成什么样”。没有范围数据，后面的原因分析容易变成印象判断。建议选取最近一到两个迭代已进入开发或已交付的用户故事作为样本，按迭代、模块、需求来源三个维度分层抽取，保证样本覆盖不同来源和不同复杂度，避免只看到某一类故事。
统计时把“缺失”拆成三种形态，分别计数：
- 完全没有验收条件：故事只有角色、目标、价值描述，没有任何可验证的结果说明。
- 只有模糊描述：写了“体验流畅”“性能良好”“操作方便”之类无法判定的表述，形式上存在，实质上不可验证。
- 验收条件与功能描述重复：把功能步骤或界面操作复述一遍，没有给出通过与否的判定依据。
三种形态指向的原因不同：第一种多与模板和流程有关，第二种多与写法能力有关，第三种多与对验收条件作用的理解有关。分开统计，后续排查才有针对性。
抽样表可以按下面的结构填写，样本量建议不少于二十个故事，模块和来源各至少覆盖两类：
| 统计项 | 填写内容 | 用途 |
|---|---|---|
| 样本范围 | 迭代编号、模块、需求来源、样本量 | 说明结论的适用范围 |
| 缺失比例 | 缺少验收条件的故事数 ÷ 样本量 | 判断是个别遗漏还是系统性缺失 |
| 形态分布 | 完全缺失、模糊描述、与功能重复各占多少 | 指向不同的原因方向 |
| 来源分布 | 不同需求来源的缺失比例 | 识别是否集中在某类来源或某个团队 |
如果缺失比例在多数模块普遍偏高，按系统性缺失处理，重点查模板和流程；如果集中在个别模块或个别来源，先查该范围的协作习惯和评审执行情况。需要说明的是，本文讨论的是需求表示层面——验收条件有没有写、写得能不能判定；需求内容本身是否合理、业务价值是否成立，属于需求分析与澄清的范围，不在本文展开。
原因假设与排除证据：验收条件为什么没写下来
缺失比例拿到后，进入原因验证。做法是先列假设，再为每条假设找可回看的证据，按“模板—评审—职责—能力”的顺序逐条排除。顺序这样安排，是因为越靠前的因素影响面越大，先排除可以避免在个别写法问题上花过多时间。
| 假设 | 验证证据 | 判定标准 |
|---|---|---|
| 故事模板与需求字段中没有验收条件的位置 | 查看当前需求模板、工作项字段配置和历史需求记录 | 模板无该字段，或字段存在但长期为空，说明缺少承载位置 |
| 评审标准只覆盖功能描述 | 回看近几次需求评审记录与通过条件 | 评审意见集中在功能是否完整，未出现对可验证结果的质询 |
| 职责不清，验收条件被默认交给测试环节 | 确认需求文档的编写人、审核人及测试介入时点 | 需求阶段无人对验收条件负责，测试在开发完成后才首次接触需求 |
| 团队对验收条件写法不熟悉 | 抽查已写验收条件的故事，看是否可观察、可判定 | 已写条目中模糊描述或功能复述占比高 |
逐条验证时注意两点。第一，证据要能回看，模板截图、评审记录、字段填写情况都属于可回看的材料，口头印象不算。第二，多条假设可能同时成立，例如模板没有字段，同时评审也不检查，这时两类原因都要处理，只改模板而不改评审，缺失仍会复发。
排查顺序与每步所需证据如下：
- 查模板：调取当前需求模板和工作项字段配置，确认是否存在验收条件的承载位置，再看历史记录中该位置的填写率。
- 查评审：抽取若干次需求评审记录，统计评审意见中涉及可验证结果的条目占比，判断评审是否把验收条件作为通过条件。
- 查职责：梳理需求从提出到进入开发的流转，确认每个环节由谁编写、谁审核验收条件，找出无人负责的断点。
- 查能力：抽查已写验收条件的质量，若模糊描述和功能复述占比高，说明需要写法训练和示例参照。
四步走完，通常会得到一张“主要原因—证据—影响范围”的对应关系。原因确认后再进入补齐，避免把猜测直接当成结论去改流程。
补齐验收条件：按故事逐条补写的处置步骤
补齐的目标是让每个故事都能据此判断通过与否，并且需求提出方、开发、测试三方理解一致。操作上以场景或业务规则为线索，一个故事可以对应多条验收条目，每条都要可观察、可判定。
第一步，确定线索。功能型故事按用户操作场景拆，规则型故事按业务规则拆，例如金额计算、权限范围、状态流转。线索确定后，逐条写出“在什么条件下、执行什么动作、观察到什么结果”。
第二步，覆盖三类条目，避免只写顺利情况：
- 正常路径：主要场景下输入合法数据，系统给出预期结果。
- 边界条件：数量上限、时间边界、空值、重复提交等临界情况下的表现。
- 异常处理：输入非法、依赖服务不可用、权限不足时的提示与数据状态。
第三步，共同确认。补齐后的条目由需求提出方确认业务预期，开发和测试确认可实现、可验证，三方对同一条目的理解一致才算完成。仍有分歧的条目单独标注为待澄清，不与已确认条目混在一起。
第四步，设置停止点。对无法立即补齐的故事，例如业务规则本身还没定、关键输入方未到场，处理方式是暂不进入开发，先澄清需求内容，而不是带着空白验收条件开工。这条停止点需要团队事先约定并写进流转规则，否则执行时容易被进度压力绕过。
补齐过程可以借助工具减少遗漏。ONES 的需求工作项与 Wiki 页面承载故事描述和验收条目，ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，在需求澄清与录入环节提炼待澄清问题与拆解建议，帮助团队把补齐后的条目更快落到可追踪的工作项上；相关输出仍需由需求提出方、开发和测试确认。具体字段配置与校验方式以实际产品配置为准。
补齐完成后形成两份产物：一份是补齐后的用户故事验收条件清单，另一份是待澄清条目列表，后者要指定澄清责任人和期望完成时间，避免长期挂起。
验证恢复与防止复发：把验收条件纳入日常检查
补齐是否有效，要看两件事：拿补齐后的故事能否直接判断通过与否，以及开发和测试对同一条目的理解是否一致。验证方式是抽查，从补齐的故事中抽取一部分，请开发和测试分别依据验收条件判断某个场景是否通过，若结论不一致，说明条目仍有歧义，需要回到补齐步骤修订。
防止复发靠三个固定检查点：
- 模板必填：在需求模板中固定验收条件字段并设为必填，让缺失在提交环节就暴露。字段是否支持必填校验，以所用工具的实际配置为准。
- 评审通过条件：在需求评审的通过条件中加入验收条件完整性检查，评审时逐条确认正常路径、边界条件和异常处理是否覆盖，未覆盖的不予通过。
- 定期复查：按迭代或按月抽样复查缺失比例和形态分布，与首次抽样数据对比，观察是否下降、模糊描述是否减少。
复查指标建议固定为三项：缺失比例、模糊描述占比、待澄清条目平均关闭时长。前两项反映表示质量，第三项反映澄清是否真正闭环。指标连续两个周期没有改善时，回到原因排查环节，检查是模板、评审还是职责环节出现了松动。
在工具层面，ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，评审状态与工作项记录可以支撑上述检查点的留痕与复查。把验收条件字段、评审检查项和复查指标落到同一套工作项与文档流程中，团队每次评审和每次抽样都有据可查，缺失问题才能从一次性补齐转为持续可控。
常见问题
抽样时样本量取多少比较合适，只抽一个迭代够不够？
建议样本量不少于二十个故事，模块和需求来源各至少覆盖两类。只抽一个迭代在团队规模小、故事数量少时可能不够，容易把个别模块的协作习惯误判为系统性缺失。可以取最近一到两个迭代已进入开发或已交付的故事，兼顾覆盖面和可回看性。如果首次抽样发现缺失比例在多数模块普遍偏高，可以再扩大样本确认，但不必等到样本齐全才开始排查模板和评审环节。
验收条件和测试用例是什么关系，写了验收条件还需要写测试用例吗？
两者处在不同环节。验收条件写在需求表示层面，用来判断一个故事是否达到通过标准，是需求提出方、开发、测试共同确认的对象；测试用例是测试环节的执行设计，关注具体步骤、数据和预期结果。验收条件可以作为测试用例的设计输入，但覆盖不了测试用例的细化程度。反过来，测试用例也不能替代验收条件，因为验收条件需要在开发开始前就明确，用于对齐三方理解。
业务规则本身还没定，验收条件补不出来怎么办？
这种情况属于需求内容尚未澄清，处理方式是设置停止点：该故事暂不进入开发，先由需求提出方牵头把业务规则定下来，再回到补齐步骤。停止点需要团队事先约定并写进流转规则，否则执行时容易被进度压力绕过。待澄清条目要单独列出，指定澄清责任人和期望完成时间，避免长期挂起。把这类故事和已确认验收条件的故事分开管理，可以避免空白条目混入开发排期。
补齐验收条件后，怎么判断条目是否真的可判定？
用抽查验证：从补齐的故事中抽取一部分，请开发和测试分别依据验收条件判断某个场景是否通过，若两人结论不一致，说明条目仍有歧义，需要回到补齐步骤修订。也可以请需求提出方按条目判断业务预期是否被准确表达。验证时重点看模糊表述是否已替换为具体条件、结果和判定依据，边界条件和异常处理是否覆盖，而不只是看条目数量是否增加。
复查指标连续没有改善，应该从哪里入手？
回到原因排查环节，按模板、评审、职责、能力的顺序重新检查哪一环出现松动。常见情况是模板字段还在但填写流于形式，或者评审通过条件里加入了检查项但执行时被跳过。复查时除了看缺失比例，还要看模糊描述占比和待澄清条目平均关闭时长，前者反映表示质量，后者反映澄清是否真正闭环。找到松动的环节后，针对该环节调整检查方式，而不是重复一轮全面补齐。
