用户故事编写规范要解决的是“谁在什么场景下要什么、为什么”，并把写法、拆分、验收与评审固化成可执行动作。本文给出一套可直接起草的规范骨架：模板与字段、编写步骤、拆分粒度、验收标准写法、角色分工和评审清单，并在故事条目、验收标准与评审记录需要承载时，说明如何用ONES需求管理承接这些对象。
要点总览（TL;DR）
- 规范文档建议固定六块：标准句式与变体、字段清单、拆分规则、验收标准写法、评审流程与检查项、正反示例，前四块定写法，后两块定确认方式。
- 编写一条故事按输入、动作、输出、完成标志推进，角色明确、价值可说明、验收标准可测三项齐备才提交评审。
- 拆分按角色、流程步骤、业务规则、数据变体四种方式选择，INVEST 用作自检清单，重点看可估算与可测试。
- 验收标准可用场景式或清单式，需覆盖正常、异常与边界，把“友好”“快速”等表述替换为可观察结果。
- 评审逐项核对角色、价值、验收标准、粒度、依赖五项，任一项不满足即阻断进入开发，规范按季度或流程重大变化时复盘。
规范文档先定哪几块：模板、字段与边界
一份能落地的用户故事编写规范，文档骨架建议固定为六块：标准句式与变体、字段清单与填写说明、拆分规则、验收标准写法、评审流程与检查项、正反示例。前四块定义“写成什么样”，后两块定义“怎么确认写对了”。规范文档控制在团队能在一小时内读完并查阅的长度，把详细解释放到附录示例中。
标准句式采用“作为<角色>，我希望<目标>，以便<价值>”。如果团队需要变体，例如面向外部用户的“我想要……从而……”，应在规范中写明适用场景和禁用场景，同一团队内保持一种主句式，避免同一需求池里出现多种写法导致检索和评审口径不一致。
必填字段建议如下表，规范中要为每个字段写明填写要求和常见错误：
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 角色 | 具体到业务角色或用户类型，可识别 | 写“用户”“系统”等笼统主体 |
| 目标 | 描述角色要完成的一件事 | 把多个目标塞进一条故事 |
| 价值 | 说明为什么需要，指向业务或使用结果 | 写“为了更好用”等空泛理由 |
| 验收标准 | 可逐条验证的条件 | 写“体验流畅”等不可测表述 |
| 优先级 | 按团队约定分级，并说明依据 | 全部标为高优先级 |
| 来源 | 记录需求线索出处，便于追溯 | 留空，后续无法回溯 |
规范还要写明适用范围与不覆盖的内容。用户故事规范约束的是需求表达形式，系统架构设计、UI 绘制与交互设计、需求内容本身的业务判断不在其内，这些议题分别由架构文档、设计稿和需求分析澄清流程处理。把边界写清楚，可以避免规范被当成万能模板，也能让评审时聚焦在表达质量上。
编写步骤：从需求线索到一条合格故事
编写一条用户故事可以按“输入—动作—输出—完成标志”四段推进，每一步都有明确产物，便于新成员照着做。
输入：业务目标或问题描述、可识别的用户角色、场景线索（用户在什么情况下遇到什么问题）。这些材料通常来自需求访谈、业务方反馈或数据分析，编写前应确认线索来源已记录。
动作：
- 识别角色。从场景线索中确认是谁在操作，必要时区分主要角色与受影响角色。
- 写目标与价值。用标准句式写出角色要完成的事，并说明完成后带来什么结果。
- 补验收标准。把“做完”的判断条件逐条写出，覆盖正常路径和至少一个异常或边界情况。
- 标注优先级与来源。按团队约定给出优先级，并记录线索出处。
输出：一条可进入评审的故事条目，包含全部必填字段。
完成标志：角色明确且可识别；价值能用一句话说明；验收标准每条都能被测试或业务方判断通过与否。三项都满足才提交评审，缺一项则退回补充。
拆分与粒度：故事多大才算合适
拆分的目标是让一条故事能在一个迭代内完成开发、测试和验收。常见拆分方式有四种：按角色拆（不同角色操作同一功能）、按流程步骤拆（一个完整流程分成若干可交付步骤）、按业务规则拆（不同规则分支独立成条）、按数据变体拆（不同数据类型或来源分别处理）。选择哪种方式取决于故事过大的原因，规范中可以给出对照表帮助判断。
| 拆分方式 | 适用情形 | 拆分后检查 |
|---|---|---|
| 按角色 | 多个角色使用同一功能但诉求不同 | 每条仍有独立价值 |
| 按流程步骤 | 端到端流程过长 | 每步可单独验收 |
| 按业务规则 | 规则分支多且可独立交付 | 规则之间依赖已标注 |
| 按数据变体 | 不同数据来源或类型处理差异大 | 变体覆盖完整 |
粒度判断可参考 INVEST 原则：独立、可协商、有价值、可估算、小、可测试。实际使用时把它当作自检清单而非硬性门槛，重点看“可估算”和“可测试”两项，因为这两项直接决定故事能否进入开发。
过大的信号包括：验收标准超过七八条且分属不同场景、估算时团队无法给出统一量级、故事标题需要用“和”连接多个动作。处理方式是回到拆分方式对照表，找到过大的原因再切分。过小的信号包括：单独一条故事无法向业务方说明价值、多条故事必须一起上线才有意义。处理方式是把它们合并为一条，或在规范中允许“技术任务”单独记录，与用户故事区分管理。
验收标准怎么写：可验证的表述方式
验收标准有两种常用写法，规范中应指定主写法并说明另一种的使用场景。场景式采用 Given/When/Then 结构，适合有明确触发条件和状态变化的业务；清单式用条目列出必须满足的条件，适合规则较多或偏配置类的需求。
场景式示例结构：
- Given 用户已登录且购物车中有商品，When 点击结算并选择在线支付，Then 生成待支付订单并跳转支付页。
- Given 支付超时未完成，When 超过约定时限，Then 订单状态变为已取消并释放库存。
清单式示例结构：
- 订单列表按创建时间倒序展示。
- 单页最多展示 20 条，超出部分分页加载。
- 无订单时展示空状态提示。
无论哪种写法，都要覆盖三类情况：正常路径、异常路径、边界条件。异常路径包括失败、超时、权限不足等；边界条件包括数量上限、空值、极端输入。规范中应列出禁用词清单，例如“友好”“快速”“合理”“尽量”，并要求把这类表述替换为可观察的结果，如“响应时间不超过 2 秒”“错误提示包含具体原因”。
角色分工与交付物：谁写、谁评审、谁确认
规范落地需要明确每个角色的动作和产物，避免出现“大家都觉得该写、但没人负责”的情况。下表给出一种常见分工，团队可按规模裁剪：
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 产品负责人 | 主导编写故事、说明价值、维护优先级 | 故事条目、优先级说明 |
| 开发 | 参与拆分、确认可行性与依赖 | 拆分建议、依赖标注 |
| 测试 | 参与验收标准评审、补充异常与边界 | 验收标准修订意见 |
| 业务方 | 确认价值与优先级、参与验收 | 确认记录 |
评审环节的产物是评审记录，至少包含参与人、结论和待办项。需求变更时，由产品负责人更新故事正文与验收标准，并在评审记录中注明变更原因和影响范围；开发和测试据此判断是否需要重新估算。把更新责任固定到角色而非个人，可以减少人员变动带来的规范失效。
故事条目、验收标准和评审记录需要有统一的承载位置，否则规范容易停留在文档里。ONES 需求管理可以承接这类对象，把故事字段、验收标准与评审结论放在同一条需求记录上，便于开发和测试在进入开发前查阅同一份信息。
完整示例：一条故事从草稿到可开发
以下为演示情景，用于说明方法如何串联，不代表真实项目数据。
草稿版本：“用户希望能导出报表，方便查看数据。”这条草稿的问题在于角色笼统、目标包含多个可能动作、价值不可判断、没有验收标准，无法估算也无法测试。
按模板改写后：作为运营专员，我希望按日期范围导出订单明细报表，以便在月度复盘中核对各渠道成交情况。验收标准采用清单式：
- 可选择开始日期与结束日期，结束日期不早于开始日期。
- 导出文件包含订单号、下单时间、渠道、金额四列。
- 所选范围内无数据时，提示“当前范围无数据”且不生成空文件。
- 单次导出上限为 5 万条，超出时提示缩小范围。
拆分说明：如果该故事同时要求支持多种文件格式和定时自动导出，则按业务规则拆为“手动导出订单明细”和“定时导出订单明细”两条，前者优先，因为运营复盘首先需要手动核对。拆分后每条故事仍保留独立价值和完整验收标准，优先级依据业务方确认的复盘时间确定。
评审与完成检查：规范是否真的被执行
规范是否被执行，靠可逐项核对的检查清单来判断。建议在故事进入开发前设置一道评审，逐项核对以下五项：
- 角色：是否具体可识别，是否存在笼统主体。
- 价值：能否用一句话说明为什么需要。
- 验收标准：是否覆盖正常、异常与边界，是否存在不可测表述。
- 粒度：是否可在一个迭代内完成，是否仍包含多个目标。
- 依赖：是否标注了前置需求、外部系统或数据依赖。
通过标准是五项全部满足；任一项不满足即阻断进入开发，退回补充后重新评审。阻断项应记录在评审记录中，便于复盘时统计高频问题。规范本身建议按季度或发生重大流程变化时复盘一次，复盘输入包括评审记录中的阻断原因分布和开发过程中的返工情况，输出是对模板字段或检查项的修订。
检查清单的价值在于把“写得好不好”变成可核对的条目。团队规模较小时可以合并评审环节，但五项检查内容建议保留，因为它们分别对应故事能否被理解、被估算和被验证。
常见问题
团队已经有需求文档模板，还需要单独的用户故事编写规范吗？
两者约束的对象不同。需求文档模板通常面向完整需求说明，覆盖背景、范围、方案等内容；用户故事编写规范约束的是进入迭代前的故事条目，重点是角色、价值、验收标准和粒度。如果团队的故事直接写在需求文档里，可以把规范中的字段和检查项并入现有模板，作为其中一节，不必另建一套文档体系。判断标准是：开发和测试能否只凭这条故事判断做什么、做到什么程度算完成。
故事由产品负责人一个人写，还是让开发和测试一起参与？
常见做法是产品负责人主导编写，开发和测试在拆分与验收标准环节参与。开发参与能提前暴露可行性与依赖问题，测试参与能补上异常路径和边界条件，这两类信息往往在编写阶段最容易被遗漏。团队规模较小时可以合并评审环节，但建议保留开发和测试对验收标准的确认动作，否则故事进入开发后容易出现理解偏差和返工。
验收标准写多少条合适，写多了是不是说明故事该拆了？
条数本身不是判断依据，关键看这些条件是否属于同一场景。如果七八条验收标准都围绕同一个角色的同一个目标，属于正常范围；如果它们分属不同场景、不同角色或不同规则分支，通常说明故事包含多个目标，应考虑按流程步骤或业务规则拆分。拆分后每条故事保留自己的验收标准，评审时逐条核对是否可测。
需求变更后，原来的验收标准和评审记录怎么处理？
由产品负责人更新故事正文与验收标准，并在评审记录中注明变更原因和影响范围，开发和测试据此判断是否需要重新估算。旧版本的验收标准建议保留在记录中，便于回溯当时为什么这样定义。把更新责任固定到角色而非个人，可以减少人员变动后规范失效的情况。
规范执行一段时间后，怎么判断它是否还有效？
可以从两个输入看：评审记录中阻断原因的分布，以及开发过程中的返工情况。如果某类阻断原因反复出现，说明模板字段或检查项需要调整；如果返工集中在验收标准理解不一致，说明写法示例需要补充。建议按季度或发生重大流程变化时复盘一次，输出对模板字段或检查项的修订，而不是只增加检查条目。
