用户故事编写规范要解决的是“写什么、写到什么程度、谁来把关”三个问题。本文给出一套可直接落地的最小规范：故事卡字段表、验收条件写法约定、拆分与就绪检查清单、角色职责表，以及用于判断规范是否真正执行的完成检查表。适用于正在制定或修订团队需求表达规则的产品负责人和需求管理人员，可结合团队规模与迭代节奏裁剪。
要点总览（TL;DR）
- 一份可执行的最小规范包含四件事：故事卡写什么、验收条件怎么写、什么状态算可以进入开发、谁在哪个环节负责，先落地前三项再补角色分工与维护机制。
- 故事卡按角色、目标、价值三段式填写，标题用“角色动作+对象”，角色限定到具体使用者，价值写成可观察的业务结果，INVEST 自检作为提交前的勾选项。
- 验收条件采用“给定—当—则”场景式写法，边界与异常场景单独成条，每条都要能被第三方判定通过或不通过，测试用例据此展开而不改变判定结论。
- 拆分按业务规则、数据、操作路径三个维度切分，拆分后每条故事仍能回答“谁、要什么、为什么”；就绪检查逐项确认后才进入迭代。
- 规范是否落地看实际故事与评审记录：抽查字段完整性、验收条件可验证性、就绪退回原因与变更留痕，先单组试点再按复盘结果修订模板。
一份可用的用户故事规范包含哪些要素
一份能执行的用户故事规范，最小构成是四件事：故事卡写什么、验收条件怎么写、什么状态算可以进入开发、谁在哪个环节负责。规范文档不必写成长篇制度，但每个要素都要落到可核对的字段或判定项上，否则执行时会退回到口头约定。
故事卡采用三段式：角色、目标、价值。角色指具体使用者或使用方，目标指该角色要完成的事，价值指完成后带来的业务结果。三段式的作用是让故事保持“以使用者为中心”的表达，避免写成功能清单。
验收条件与故事正文分开写。故事正文回答“为谁解决什么问题”，验收条件回答“怎样算做完”。两者混写会导致故事越写越长、验收标准被叙述淹没，评审时也难以逐条确认。
就绪标准与完成标准要区分开。就绪标准（Definition of Ready）描述故事进入迭代前应满足的条件，例如字段完整、验收条件已确认、依赖已识别；完成标准（Definition of Done）描述故事交付时应达到的状态，例如验收条件全部通过、相关文档已更新。前者是准入，后者是出口，混用会让团队在错误的时间点做判断。
规范文档本身应包含以下字段级清单，作为后续章节展开的骨架：
| 要素 | 规范中要写清的内容 | 判定合格的方式 |
|---|---|---|
| 故事卡模板 | 标题、角色、目标、价值、优先级、估算、依赖、验收条件入口 | 任取一条故事，字段无空缺或空缺有说明 |
| 验收条件写法 | 场景式结构、边界与异常覆盖要求 | 每条验收条件可被第三方判定通过或不通过 |
| 拆分规则 | 拆分维度、独立价值要求、粒度信号 | 拆分后的故事可单独排期与验收 |
| 就绪标准 | 进入迭代前的检查项 | 评审会上逐项确认，未满足不进入迭代 |
| 角色与交付物 | 谁写、谁评审、谁维护变更 | 每条故事有明确责任人和评审记录 |
| 规范维护机制 | 更新触发条件、审批人、版本记录 | 规范文档有版本号与修订记录 |
这份清单同时是规范文档的目录。团队初次制定时，可以只保留故事卡模板、验收条件约定和就绪标准三项，运行一两个迭代后再补充角色分工与维护机制。
故事卡模板与字段填写规则
故事卡模板的价值在于把填写口径固定下来，让不同人写出的故事具备可比性。下面是一份可直接复制的字段表，每个字段都给出填写要求。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 故事标题 | 动宾结构，包含操作对象，控制在便于列表浏览的长度 | 写成模块名或“优化XX”这类无对象表述 |
| 角色 | 限定到具体使用者或使用方，如“负责月度对账的财务专员” | 只写“用户”“管理员” |
| 目标 | 该角色要完成的具体动作或达成的状态 | 把实现方式写进目标 |
| 价值 | 完成后对业务或使用者的可观察结果 | 写“提升体验”这类无法验证的判断 |
| 验收条件 | 单独成节，按场景逐条列出 | 与正文混写，或只写一句“功能正常” |
| 优先级 | 按统一口径标注，如业务价值与紧急度组合 | 全部标为高优先级 |
| 估算 | 使用团队统一的估算单位，注明是否含测试 | 估算口径随人变化 |
| 依赖 | 列出前置故事、外部系统或数据条件 | 依赖在开发阶段才被发现 |
标题命名建议统一为“角色动作+对象”，例如“财务专员导出月度对账明细”。这样在需求列表中可以直接看出故事范围，减少点开详情才能理解的成本。
角色描述要避免泛化。“用户”无法指导设计与验收，应写明使用场景中的具体身份或职责。当一条故事涉及多个角色时，优先选择主要受益角色，其余角色放入验收条件或拆成独立故事。
价值描述要与业务目标对应。写法上可以回答“完成后谁可以少做什么、多得到什么”。如果价值无法说清，通常说明这条故事是从实现方案倒推出来的，需要回到需求来源确认。
优先级、估算、依赖属于辅助字段，但填写口径必须统一。优先级建议由产品负责人按同一套规则标注并在评审时说明理由；估算由开发人员在理解验收条件后给出；依赖字段要求填写人主动确认前置条件，评审时作为就绪检查的一项。
INVEST 自检可以嵌入模板，作为故事卡末尾的一组勾选项：独立（可单独排期）、可协商（细节留待讨论）、有价值、可估算、足够小、可测试。自检不替代评审，但能让填写人在提交前先排除明显不合格的故事。
验收条件怎么写才可验证
可验证的验收条件有两个特征：第三方按条件操作能得出通过或不通过的结论；条件描述的是可观察的行为或结果，而非主观感受。推荐使用场景式写法，即“给定—当—则”结构：给定某个前置状态，当执行某个操作，则出现某个可观察结果。
场景式写法的好处是把前置条件显式化。很多验收争议来自前置状态没有说清，例如数据为空、权限不同、状态已变更。把这些条件写进“给定”部分，测试和开发对同一条故事的理解才能对齐。
边界与异常场景要单独覆盖。常规路径之外，至少考虑：输入为空或超限、权限不足、并发或重复提交、外部依赖失败。每条边界场景写成独立场景，不要合并为“异常情况需处理”。
验收条件与测试用例的衔接方式是：验收条件描述业务上“怎样算对”，测试用例描述具体操作步骤与数据。一条验收条件通常对应一条或多条测试用例，测试人员在编写用例时不应改变验收条件的判定结论，发现歧义应回到故事评审确认。
不可验证表述的改写示例如下：
| 原始表述 | 问题 | 改写后 |
|---|---|---|
| 导出功能要快 | “快”无判定标准 | 给定单月不超过一万条记录，当点击导出，则在合理等待时间内生成文件并可下载 |
| 界面友好易用 | 主观判断 | 给定新用户首次进入，当完成主要操作，则无需查阅说明即可完成，关键字段有提示文案 |
| 异常要有提示 | 未说明何种异常、提示什么 | 给定必填项为空，当提交，则停留在当前页并在对应字段显示缺失提示 |
| 支持多种格式 | 范围不明 | 给定导出操作，当选择格式，则提供规范中列明的格式选项，并按所选格式生成文件 |
改写时保留原有业务意图，只把判定标准补足。涉及性能、容量等指标时，应写明测量条件与范围；如果团队暂时没有统一口径，先在规范中约定一个可执行的临时标准，并在复盘中修订。
故事拆分与就绪判断的操作步骤
拆分的目标是让每条故事能被单独排期、单独验收。常见拆分维度有三类：按业务规则拆，例如不同计费规则各自成条；按数据拆，例如不同来源或类型的数据分别处理；按操作路径拆，例如查询、编辑、导出分别成条。选择维度时以“拆分后每条仍有独立价值”为准。
操作步骤可以按以下顺序执行：
- 确认原始需求的角色与价值，写清这条大需求解决谁的什么问题。
- 列出其中的业务规则、数据范围和操作路径，作为拆分候选维度。
- 按候选维度切分，检查每条故事是否仍能回答“谁、要什么、为什么”。
- 为每条故事补写验收条件，确认可独立验证。
- 标注依赖关系与优先级，进入就绪检查。
就绪检查的判定项建议包括：故事卡字段完整；验收条件已由需求提出方与测试确认；依赖已识别并有处理安排；估算已完成；故事粒度可在单个迭代内完成。全部满足才进入迭代，任一项未满足则退回补充，并在评审记录中写明原因。
拆分过细的信号：故事无法独立产生可观察价值，多条故事必须一起上线才有意义；验收条件几乎相同，只是数据不同；故事数量增长但评审时间显著拉长。拆分过粗的信号：一条故事包含多个角色或多个不相关的操作路径；验收条件超过一屏且难以逐条确认；估算时开发人员无法给出稳定结论。出现这些信号时，回到拆分维度重新切分。
角色分工与交付物：谁写、谁评审、谁维护
规范能否执行，取决于每个环节是否有明确的责任人和产出物。下表给出一份可直接采用的分工方案，团队可按规模调整角色名称，但职责边界应保持清晰。
| 环节 | 责任人 | 输入 | 交付物 |
|---|---|---|---|
| 故事起草 | 产品负责人或需求提出方 | 业务目标、使用场景、已有反馈 | 故事卡初稿 |
| 验收条件编写 | 产品负责人主笔，测试参与 | 故事卡初稿、业务规则 | 场景式验收条件 |
| 评审 | 产品、开发、测试共同参与 | 故事卡、验收条件、依赖说明 | 评审意见与就绪结论 |
| 估算与排期 | 开发人员 | 已确认的故事卡与验收条件 | 估算结果、迭代排期 |
| 变更维护 | 产品负责人 | 变更请求、评审记录 | 更新后的故事卡与变更说明 |
| 规范维护 | 指定的规范负责人 | 复盘问题、团队反馈 | 规范新版本与修订记录 |
需求提出方负责说明业务背景与价值判断，不直接决定实现方式；产品负责人对故事卡的完整性和优先级负责；开发人员在评审中确认可估算、依赖可处理；测试人员确认验收条件可验证，并在后续将其转化为测试用例。评审会的输入是已完成初稿的故事卡与验收条件，输出是就绪结论或退回意见，二者都要留痕。
故事变更由产品负责人统一维护，变更需记录原因、影响范围和重新评审结论。规范本身的更新建议按固定节奏进行，例如每个季度或每若干迭代复盘一次，由规范负责人汇总执行中的问题并发布新版本，修订记录保留在规范文档内。
当团队使用需求管理工具承载这套规范时，故事卡、验收条件与评审记录需要有稳定的存放位置。ONES Wiki 支持页面模板库，可将故事卡模板与验收条件约定做成制式化文档，并通过页面树组织规范与示例；文档记录页面版本并支持查看与回滚，便于追踪规范修订。ONES TestCase 支持测试用例与需求、任务关联，验收条件转化为用例后可保持与故事的对应关系，未通过的用例可快速创建缺陷任务。具体字段配置与关联方式以实际产品配置为准。
示例：一条用户故事从草稿到就绪
以下示例为演示情景，用于说明模板、验收条件与评审的实际填写过程。
草稿版故事：“做一个对账导出功能，支持导出 Excel，越快越好，异常要有提示。”这条草稿的典型问题包括：没有角色，无法判断谁受益；价值缺失，只有实现方案；验收条件不可验证，“越快越好”和“异常要有提示”都没有判定标准；粒度不清，未说明数据范围与权限。
按模板改写后的故事卡：
| 字段 | 内容 |
|---|---|
| 标题 | 财务专员导出月度对账明细 |
| 角色 | 负责月度对账的财务专员 |
| 目标 | 按月份导出对账明细文件，用于线下核对 |
| 价值 | 对账准备从手工整理转为直接使用导出结果，减少重复录入 |
| 优先级 | 高（月度对账有固定时间窗口） |
| 估算 | 按团队统一单位估算，含测试 |
| 依赖 | 对账数据来源已就绪；导出权限规则已确认 |
配套验收条件：
- 给定财务专员已登录且有导出权限，当选择某个月份并点击导出，则生成包含该月对账明细的文件并可下载。
- 给定所选月份无对账数据，当点击导出，则提示无数据且不生成空文件。
- 给定当前账号无导出权限，当进入对账页面，则不显示导出入口。
- 给定单月记录数超过约定上限，当点击导出，则按规范约定的方式处理并给出明确提示。
评审意见与修订结果：开发人员提出“约定上限”未写明，修订为规范中列明的具体范围；测试人员提出无数据场景需区分“月份未到”和“确实无记录”，补充一条场景；产品负责人确认依赖中的权限规则已与相关方对齐。修订后故事卡字段完整、验收条件逐条可判定，评审结论为就绪，进入迭代排期。
规范落地后的完成检查
判断规范是否真正执行，不能只看文档是否存在，而要抽查实际故事与评审记录。以下检查表可按迭代或按月执行，每项给出可核验的判定方式。
| 检查项 | 核验方式 | 合格判定 |
|---|---|---|
| 故事卡字段完整性 | 随机抽取本迭代故事，逐字段核对 | 必填字段无空缺，空缺有书面说明 |
| INVEST 自检结果 | 查看故事卡自检勾选项 | 自检已完成，未通过项有处理记录 |
| 验收条件可验证性 | 抽取若干条验收条件，请未参与编写的人员判断 | 能独立得出通过或不通过结论 |
| 就绪标准执行情况 | 对照评审记录检查进入迭代的故事 | 未满足就绪项的故事未进入迭代，退回原因有记录 |
| 评审记录与变更留痕 | 抽查变更故事 | 变更原因、影响范围、重新评审结论齐全 |
| 规范版本维护 | 查看规范文档修订记录 | 有版本号与最近一次修订说明 |
推广节奏建议先在单个迭代或单个小组试点，收集填写耗时、评审退回率、验收争议次数等可观察信号，再决定是否扩大范围。复盘节点可以设在试点迭代结束后和规范发布后的第一个季度，复盘内容聚焦检查表中不合格项的原因，据此修订模板或就绪标准，而不是增加更多文档要求。
常见问题
团队刚起步，规范要不要一次写全？
不必。初次制定时保留故事卡模板、验收条件写法约定和就绪标准三项即可，这三项直接决定故事能不能被评审和排期。运行一两个迭代后，再补充角色分工表与规范维护机制，此时团队已经积累了对退回原因和填写耗时的实际感受，补充的条款更有针对性。
规范文档本身保留版本号与修订记录，后续每次调整都能追溯到触发原因。
故事卡里的价值写不出来，通常是什么原因？
常见原因是这条故事从实现方案倒推而来，先定了做法再补理由。可以回到需求来源，问清完成后谁可以少做什么、多得到什么，把答案写成可观察的业务结果。如果仍然说不清，说明这条故事可能只是某个更大需求的技术步骤，应回到拆分环节重新确认它服务于哪个角色和目标。
验收条件与测试用例的边界在哪里？
验收条件描述业务上“怎样算对”，用场景式结构写清前置状态、操作和可观察结果；测试用例描述具体操作步骤与测试数据。一条验收条件通常对应一条或多条用例。测试人员在编写用例时发现歧义，应回到故事评审确认，由产品负责人修订验收条件，避免在用例层面单方面改变判定结论。
故事在迭代中被变更，规范怎么处理？
变更由产品负责人统一维护，记录变更原因、影响范围和重新评审结论，三项齐全才算完成变更。若变更涉及验收条件，需要测试重新确认可验证性；若涉及依赖，需要开发确认前置条件是否仍然成立。变更记录与故事卡放在同一处，便于复盘时统计变更来源。
规范执行一段时间后效果不明显，从哪里查起？
先抽查实际故事而不是看文档。随机抽取本迭代的故事核对字段完整性，请未参与编写的人员判断验收条件能否独立得出结论，再对照评审记录看未满足就绪项的故事是否真的被退回。不合格项集中在哪个环节，就修订对应的模板或判定项，避免用增加文档数量的方式回应执行问题。
