本文给出一套可直接复制的用户故事编写规范：一张空白故事主表、一张验收条件子表，配合逐字段填写口径、必填与选填划分，以及一个从空白到成稿的完整示例。读者可以把表格粘贴到文档或表格工具中开始使用，也可以按团队规模和项目类型调整字段。文末说明模板的维护方法，避免规范用久了变成负担。
要点总览（TL;DR）
- 模板由故事主表和验收条件子表组成：主表一行一个故事，写清角色、目标、价值，子表用“AC-故事序号-条件序号”关联，逐条界定完成标准。
- 必填字段为故事编号、角色、目标、价值、验收条件和状态；优先级、估算、依赖、负责人为选填推荐项，进入排期前补齐。
- 完整示例展示一个“门店店长批量导出订单”的故事，四条验收条件分别覆盖正常路径、异常路径、边界情况和权限。
- 模板按团队规模与项目类型增减字段，每次调整记录版本、变更内容与生效日期，并同步更新字段说明和示例。
- 模板可粘贴到文档或表格工具中使用；在 ONES Wiki 中可借助页面模板库创建制式化文档，并用页面版本追踪修改记录。
可复制的用户故事空白模板
模板由两张表组成：故事主表一行记录一个用户故事，验收条件子表按故事编号关联，一个故事可以对应多条验收条件。复制时保留表头即可，示例行可以删除。
故事主表（空白）
| 故事编号 | 角色 | 目标 | 价值 | 验收条件编号 | 优先级 | 估算 | 依赖 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| US-001 | AC-001-01… | ||||||||
| US-002 | |||||||||
| US-003 |
验收条件子表（空白）
| 条件编号 | 所属故事 | 前置条件 | 操作 | 预期结果 | 类型 |
|---|---|---|---|---|---|
| AC-001-01 | US-001 | ||||
| AC-001-02 | US-001 | ||||
| AC-001-03 | US-001 |
使用说明
- 一行一个故事，故事主体只写“谁、要什么、为什么”，具体做法留给方案讨论。
- 验收条件另起子表，用“故事编号—条件编号”建立对应关系，便于逐条核对完成情况。
- 条件编号建议采用“AC-故事序号-条件序号”，故事拆分或合并时编号随之调整，避免引用错位。
- 表格可直接粘贴到文档、电子表格或需求管理工具的自定义字段中；若团队使用支持页面模板的协作工具，可把两张表保存为固定模板反复调用。
模板字段说明：每个字段写什么
字段说明与上表一一对应。故事主体三要素决定“这个需求是否值得做”，验收条件决定“做完没有”，管理字段决定“什么时候做、谁来做、卡在哪里”。
| 字段 | 写什么 | 填写口径 |
|---|---|---|
| 故事编号 | 唯一标识 | 采用“US-序号”格式，全项目内不重复，便于在讨论、提交记录和测试用例中引用。 |
| 角色 | 使用该功能的人或系统角色 | 写具体角色而非“用户”，例如“门店店长”“财务审核员”“首次注册的访客”。角色越具体，后续讨论越容易找到真实使用场景。 |
| 目标 | 角色想完成的事 | 用动词开头描述动作与对象，例如“批量导出本月订单”。目标是用户要达成的结果，不是界面按钮或技术实现。 |
| 价值 | 完成目标带来的收益 | 写对角色或业务的可观察好处，例如“减少手工整理时间”“避免漏单”。价值说不清时，先回到角色确认使用动机。 |
| 验收条件编号 | 关联子表的条件 | 列出该故事对应的全部条件编号，与子表保持一致；新增条件时同步更新主表。 |
| 优先级 | 相对重要程度 | 使用团队统一的档位，如高/中/低或数字序列，并说明排序依据（业务价值、合规要求、依赖关系）。 |
| 估算 | 工作量参考值 | 采用团队惯用单位，如故事点或人天，并注明单位；估算在故事澄清后填写，避免在信息不足时给出精确数字。 |
| 依赖 | 前置故事、外部系统或数据 | 写清依赖对象与编号，例如“依赖 US-012 的权限改造”“等待支付接口联调”。没有依赖时填“无”，避免留空造成误解。 |
| 状态 | 故事所处阶段 | 使用统一状态集，如待澄清、已就绪、开发中、待验收、已完成；状态变更时记录时间，便于观察流转。 |
| 负责人 | 当前推进人 | 写具体人名而非团队名；负责人对故事澄清、验收条件完整性和状态更新负责。 |
验收条件字段的写法
验收条件采用“前置条件—操作—预期结果”的结构，每条只验证一个可观察的结果。前置条件描述开始时的系统状态或数据准备；操作写用户或系统执行的动作；预期结果写可以判断对错的现象，包括页面反馈、数据变化或提示信息。类型字段用于区分功能正常路径、异常路径、边界情况和性能要求，方便测试时按类型覆盖。
必填与选填：哪些字段不能空
必填字段保证故事可以被理解和验收，选填字段服务于排期与协作。团队规模较小时，管理字段可以精简；跨团队协作或需求量大时，建议补齐。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 故事编号 | 必填 | 所有引用和关联的基础，缺失会导致验收条件无法对应。 |
| 角色 | 必填 | 没有角色，故事容易写成功能清单，无法判断为谁而做。 |
| 目标 | 必填 | 故事的核心内容，缺失则无法进入澄清和估算。 |
| 价值 | 必填 | 用于优先级排序和取舍；确实一时说不清时，可先写待确认并指定澄清时间。 |
| 验收条件 | 必填 | 至少一条可验证条件，否则无法判断完成；复杂故事建议覆盖正常与异常路径。 |
| 状态 | 必填 | 协作的基本信号，缺失会让其他人无法判断是否可以开始工作。 |
| 优先级 | 选填（推荐） | 小团队口头排期时可暂缓；需求数量多、多团队并行时建议必填。 |
| 估算 | 选填（推荐） | 进入迭代规划前补齐；早期探索阶段可留空，但要标注“待估算”。 |
| 依赖 | 选填 | 存在跨故事或外部依赖时必填；无依赖时填“无”，不建议直接留空。 |
| 负责人 | 选填（推荐） | 故事进入就绪状态后指定；待澄清阶段可由需求负责人统一代管。 |
字段留空的处理约定
- 必填字段留空的故事不进入“已就绪”状态，在评审时退回补充。
- 选填字段留空时写明原因或计划补齐时间，例如“估算：待技术澄清后补充”。
- “依赖”字段统一填“无”而不是留空，避免读者分不清“没有依赖”和“还没检查”。
- 验收条件少于一条的故事视为未完成编写，不参与排期。
完整填写示例：一个用户故事从空白到成稿
以下示例为演示情景，展示一张填好的主表记录和对应验收条件，字段与前面的模板保持一致。
故事主表（已填写）
| 故事编号 | 角色 | 目标 | 价值 | 验收条件编号 | 优先级 | 估算 | 依赖 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| US-021 | 门店店长 | 按日期范围批量导出订单明细 | 月末对账时减少手工整理，降低漏单风险 | AC-021-01 至 AC-021-04 | 高 | 3 故事点 | 依赖 US-018 的订单查询接口改造 | 已就绪 | 李明 |
验收条件子表（已填写）
| 条件编号 | 所属故事 | 前置条件 | 操作 | 预期结果 | 类型 |
|---|---|---|---|---|---|
| AC-021-01 | US-021 | 店长已登录，账号下存在近 30 天订单 | 选择起止日期并点击“导出” | 生成包含所选范围内全部订单的表格文件，字段与列表页一致 | 正常路径 |
| AC-021-02 | US-021 | 所选日期范围内没有订单 | 点击“导出” | 提示“所选范围无订单”，不生成空文件 | 异常路径 |
| AC-021-03 | US-021 | 所选范围订单超过 1 万条 | 点击“导出” | 提示分批导出或限制范围，并说明单次上限 | 边界情况 |
| AC-021-04 | US-021 | 店长账号仅有本门店数据权限 | 导出订单 | 文件中只包含本门店订单，不含其他门店数据 | 权限 |
逐字段填写理由
- 角色写“门店店长”而非“用户”，因为导出动作与对账职责直接相关，后续澄清可以找到真实岗位确认字段需求。
- 目标用动词开头，描述用户要完成的事；“批量导出”明确了操作对象和范围，没有提前规定按钮位置或技术方案。
- 价值落在“月末对账”和“漏单风险”上，可以直接用于优先级讨论，也方便判断这个需求是否值得投入。
- 优先级为高，依据是月度对账有固定时间窗口；估算在澄清后给出，单位写明为故事点。
- 依赖写清具体故事编号和依赖内容，排期时可以据此判断先后顺序。
- 四条验收条件分别覆盖正常路径、异常路径、边界情况和权限，每条都有可观察的预期结果，测试人员可以逐条判断通过与否。
常见填写错误对照
| 错误写法 | 问题 | 修改方向 |
|---|---|---|
| “作为用户，我要一个导出按钮，以便导出订单” | 把界面方案写进故事，角色和价值都模糊 | 改为具体角色和要完成的事，方案留到设计讨论 |
| “导出功能正常可用” | 验收条件不可验证，无法判断对错 | 写清前置、操作和可观察的预期结果 |
| “系统要快” | 缺少判断标准 | 补充可测量的条件，例如在指定数据量下的响应时间要求 |
| 一个故事挂十几条验收条件 | 故事过大，难以在一个迭代内完成 | 按用户目标拆分故事，每条故事保留少量关键条件 |
| 依赖字段留空 | 无法区分“无依赖”和“未检查” | 确认后填“无”，或写明依赖对象 |
当故事和验收条件需要在团队内长期维护时，可以把这套表格放进支持页面模板的协作工具中。ONES Wiki 提供页面模板库，可一键创建制式化文档模板；页面组可关联项目，使需求与文档互相对应；页面版本支持查看与回滚，便于追踪模板和故事的修改记录。这样，空白模板、填写规范和具体故事可以放在同一处维护，评审时直接对照字段检查。
模板的调整与维护方法
模板的价值在于让讨论有共同结构，字段过多会增加填写负担，字段过少会丢失关键信息。调整时以实际使用中的卡点为依据，而不是一次性设计得很全。
按团队规模与项目类型增减字段
- 小团队、需求来源单一：保留角色、目标、价值、验收条件、状态五项核心字段，优先级和估算在排期会上口头确认后补录。
- 多团队协作或需求量大：补齐优先级、估算、依赖和负责人，并统一状态集，避免各团队口径不一致。
- 合规、金融、医疗等项目：在验收条件中增加权限、审计或数据保留类条件，必要时增加“合规依据”字段。
- 探索型项目：允许价值字段先写假设，并增加“验证方式”字段，等验证后再补结论。
模板版本与变更记录
模板本身也需要版本管理。每次调整字段时，在模板文档顶部记录版本号、变更内容、生效日期和负责人；已进入开发的故事沿用旧版本字段，新故事使用新版本，避免中途改字段导致历史记录无法对照。若使用支持页面版本的协作工具，可保留每次修改的快照，需要时回滚到上一版。
定期评审的触发条件与做法
- 触发条件：连续多个迭代出现必填字段缺失、验收条件在测试阶段才补充、或团队反馈填写耗时明显增加。
- 评审做法：抽取最近一个迭代的故事，统计各字段的实际填写率和返工原因，据此决定增删字段，而不是凭印象调整。
- 评审节奏：建议每季度或每个大版本结束后检查一次；模板稳定后可延长间隔。
- 变更落地：调整后同步更新字段说明和填写示例，并在下一次需求评审中按新模板执行，确保模板、说明和示例三者一致。
常见问题
用户故事写多细才算合适？
判断标准是能否在一个迭代内完成，并且验收条件可以逐条验证。故事主体只写“谁、要什么、为什么”，把界面布局、接口设计等方案留到澄清和设计讨论。如果一个故事需要挂十几条验收条件，通常说明目标过大，可以按用户要完成的不同事情拆分，每条故事保留少量关键条件。
验收条件应该写几条，必须覆盖异常情况吗？
至少一条，复杂故事建议覆盖正常路径、异常路径、边界情况和权限。示例中的导出故事用四条条件分别对应这四类，测试人员可以逐条判断通过与否。条件数量以能界定“做完没有”为准，不必为每种可能情况都写一条；容易遗漏的是无数据、超量、权限受限这类场景，评审时可以专门检查。
小团队字段太多填不过来，可以砍掉哪些？
可以保留角色、目标、价值、验收条件、状态五项核心字段，优先级和估算在排期会上口头确认后补录。依赖字段在存在跨故事或外部依赖时仍需填写，没有依赖时填“无”。团队扩大或需求数量增加后，再补齐优先级、估算和负责人，并统一状态集。
模板调整后，已经进入开发的故事怎么办？
已进入开发的故事沿用旧版本字段，新故事使用新版本，避免中途改字段导致历史记录无法对照。模板文档顶部记录版本号、变更内容、生效日期和负责人；调整后同步更新字段说明和填写示例，并在下一次需求评审中按新模板执行。若在 ONES Wiki 中维护，页面版本支持查看与回滚，可保留每次修改的快照。
用户故事和验收条件放在文档里还是需求管理工具里？
取决于团队的使用习惯。文档适合承载模板、填写规范和讨论记录，需求管理工具适合承载状态流转和排期。两者可以配合：把空白模板和填写规范放在文档中维护，具体故事在工具中按字段录入。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，页面组可关联项目，使需求与文档互相对应。
