用户故事模板的填写可以按“角色—目标—价值”三要素展开，常用句式是“作为〈角色〉，我希望〈目标〉，以便〈价值〉”，再用验收标准固定“做完”的判定口径。本文提供可直接复制的空白主表与验收标准子表，逐字段说明填写方法，并给出必填选填对照和一条完整示例。用户故事最终要落到需求条目中跟踪状态与验收，ONES 可作为承载工具之一。
要点总览（TL;DR）
- 用户故事模板以“作为〈角色〉，我希望〈目标〉，以便〈价值〉”为主干，再补充验收标准、优先级、依赖、状态等字段，形成可评审、可跟踪的条目。
- 填写顺序建议先角色、再目标、最后价值；验收标准从目标反推，逐条写成可判断通过与否的条件。
- 小团队起步可用六项最小字段集：标题、角色、目标、价值、验收标准、状态；出现跨团队依赖后再启用优先级、依赖、负责人等字段。
- 不确定的内容写入“待确认事项”，避免把猜测写成确定结论；示例中安全库存阈值归属就是典型待确认项。
- 模板需要定期检视：反复被追问的信息考虑新增字段，长期无人查看的字段改为选填或移除，并保留变更记录。
可复制空白用户故事模板
下面两张表可以直接复制到文档、表格或需求管理工具中使用。主表记录故事本身，子表记录验收标准。复制时保留表头，按行填写；一条用户故事对应一张主表，验收标准可以有多行。
主表：用户故事
| 字段 | 填写内容 |
|---|---|
| 故事编号 | |
| 故事标题 | |
| 角色 | |
| 目标 | |
| 价值 | |
| 使用场景 | |
| 验收标准 | 见下方验收标准子表 |
| 优先级 | |
| 依赖 | |
| 状态 | |
| 待确认事项 | |
| 负责人 | |
| 备注 |
子表：验收标准
| 序号 | 验收条件 | 验证方式 | 结果 |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 |
复制使用时注意三点：主表一行只写一条故事，避免把多个目标塞进同一条；验收标准子表的每一行对应一个可独立判断的条件；不确定的内容先写入“待确认事项”，不要在主表里写成确定结论。若团队使用在线文档，可把两张表放在同一页面，主表下方紧跟子表，便于评审时对照阅读。
每个字段填什么：字段说明
字段说明解决“这一格该写什么、写到什么程度”的问题。三要素决定故事的方向，辅助字段决定故事能否被排期和跟踪。下表按主表顺序说明填写口径。
| 字段 | 含义与填写口径 | 容易写错的地方 |
|---|---|---|
| 故事编号 | 团队内部唯一标识，便于引用和关联依赖 | 多条故事共用编号，导致追溯困难 |
| 故事标题 | 用动词加对象概括，如“导出订单明细” | 标题写成整句需求描述，过长且难检索 |
| 角色 | 写具体使用者或角色，如“门店店长”“财务审核员” | 写成“用户”“系统”这类无法区分场景的词 |
| 目标 | 写角色想完成的具体动作或想获得的结果 | 把实现方式写进目标，如指定按钮位置 |
| 价值 | 写完成目标后带来的业务结果或使用收益 | 写成“提升体验”这类无法验证的空话 |
| 使用场景 | 补充角色在什么时机、什么条件下使用 | 与目标重复，没有增加新信息 |
| 验收标准 | 逐条写可判断通过与否的条件，放入子表 | 只写“功能正常”，评审时无法判定 |
| 优先级 | 按团队约定标注高、中、低或排序值 | 所有故事都标高，失去排序作用 |
| 依赖 | 写清依赖的其他故事、外部系统或数据 | 依赖只在口头说明，未落到字段 |
| 状态 | 按团队流程标注待评审、已确认、开发中、已验收等 | 状态长期不更新，与实际进度脱节 |
| 待确认事项 | 记录尚未澄清的问题及需要确认的人 | 把猜测写成结论，后续无人复核 |
| 负责人 | 写当前推动该故事澄清或交付的人 | 空缺导致故事无人推进 |
| 备注 | 放背景资料、讨论记录或参考链接 | 把验收标准混入备注，评审时遗漏 |
三要素的填写顺序建议是先角色、再目标、最后价值。角色写具体，目标才容易落到真实动作；目标写清楚，价值才有对应的业务结果。验收标准则从目标反推：角色完成这个动作后，系统或流程应当呈现什么结果，逐条列出即可。价值字段允许在澄清前先写初步判断，但要用“待确认事项”标明需要验证的部分。
必填与选填：最小可用字段集
模板字段并非越多越好。字段过多会增加填写负担，字段过少则难以排期和验收。下表把字段分为必填与选填，并说明适用场景。
| 类别 | 字段 | 理由与适用场景 |
|---|---|---|
| 必填 | 故事标题 | 没有标题无法检索和引用 |
| 必填 | 角色 | 决定使用场景，缺失会导致目标空泛 |
| 必填 | 目标 | 故事的核心动作，缺失则无法开发 |
| 必填 | 价值 | 用于判断优先级和是否值得做 |
| 必填 | 验收标准 | 固定“做完”的判定口径，至少一条 |
| 必填 | 状态 | 支撑评审与跟踪，避免故事停留在口头 |
| 选填 | 故事编号 | 故事数量多、需要跨文档引用时启用 |
| 选填 | 使用场景 | 角色和目标不足以说明时机时补充 |
| 选填 | 优先级 | 进入排期阶段后启用 |
| 选填 | 依赖 | 存在跨团队或外部系统依赖时必填 |
| 选填 | 待确认事项 | 澄清阶段使用，确认后可清空或归档 |
| 选填 | 负责人 | 故事进入推进阶段后指定 |
| 选填 | 备注 | 有背景资料或讨论记录时使用 |
小团队起步时可以采用最小可用字段集：标题、角色、目标、价值、验收标准、状态六项。这个组合足以支撑一次需求评审和后续验收，填写成本也低。团队协作规模扩大、出现跨团队依赖后，再逐步启用优先级、依赖和负责人字段。判断是否新增字段的标准是：这个字段是否会被实际查看并影响决策。长期无人查看的字段可以从模板中移除，减少无效填写。
填写示例：一条完整用户故事
以下示例为演示情景，用于说明各字段如何落笔，不代表真实客户案例。场景设定为一家零售企业的门店补货流程。
主表填写内容
| 字段 | 填写内容 |
|---|---|
| 故事编号 | US-014 |
| 故事标题 | 按门店库存生成补货建议 |
| 角色 | 门店店长 |
| 目标 | 查看本店低于安全库存的商品，并生成一份补货建议清单 |
| 价值 | 减少店长手工盘点比对的时间，降低断货概率 |
| 使用场景 | 每日营业结束后，店长在补货页面查看库存预警并提交建议 |
| 验收标准 | 见下方子表 |
| 优先级 | 高 |
| 依赖 | 依赖库存预警数据每日同步完成 |
| 状态 | 待评审 |
| 待确认事项 | 安全库存阈值由总部统一配置还是门店可调，需与运营确认 |
| 负责人 | 需求负责人待指定 |
| 备注 | 参考上一季度断货商品清单 |
验收标准子表填写内容
| 序号 | 验收条件 | 验证方式 | 结果 |
|---|---|---|---|
| 1 | 页面列出本店所有低于安全库存的商品，含商品名称、当前库存、安全库存 | 用测试门店数据核对列表 | |
| 2 | 店长可勾选商品并生成补货建议清单，清单包含建议补货数量 | 勾选三件商品后生成清单检查 | |
| 3 | 库存数据未同步时，页面提示数据更新时间，不展示过期数量 | 模拟同步延迟场景验证提示 |
对照字段说明可以看到：角色写成了具体岗位，目标是一个可执行的动作，价值对应到可观察的业务结果，验收标准三条分别覆盖列表内容、操作结果和异常提示。待确认事项单独记录阈值归属问题，没有混入目标或验收标准。评审时按子表逐条确认，通过后在“结果”列标注，故事状态再推进到已确认。
模板的调整与维护方法
模板投入使用后需要定期检视，避免字段越加越多或长期不更新。调整的依据来自实际使用中的摩擦，而不是一次性设计。以下清单可作为维护操作参考。
- 新增字段的判断：当同一类信息在评审中反复被口头追问、且影响排期或验收时，考虑新增字段；只出现一两次的信息先放备注。
- 删减字段的判断：连续几个迭代无人查看、也未影响决策的字段，可以从模板中移除或改为选填。
- 版本记录：每次调整模板时记录变更日期、变更内容和原因，保留旧版本以便回溯。使用 ONES Wiki 时，页面模板库可一键创建制式化文档模板，页面版本支持随时查看与回滚，便于留存模板变更记录。
- 评审机制：在需求评审中顺带检查模板字段是否够用，发现缺失当场记录，不临时改模板。
- 定期回顾：每个季度或每个大版本结束后回顾一次模板，统计字段使用情况，集中做一次增删。
- 权限与分工：明确谁可以修改模板，避免多人同时改动造成口径不一致；ONES Wiki 支持为不同角色配置读写权限，可用于区分模板维护者与使用者。
模板维护的目标是让填写动作稳定、评审口径一致。用户故事在澄清后需要落到具体需求条目中跟踪状态和验收结果，ONES 的需求管理与 Wiki 页面组可关联项目，使需求与文档互相对应，模板文档和需求条目可以放在同一项目上下文中维护。团队规模、流程成熟度和工具选型不同，字段取舍也会有差异，按实际使用情况逐步调整即可。
常见问题
用户故事模板里的“价值”字段写不出可量化的收益，还能怎么填？
价值字段不要求每条都给出精确数字。澄清前可以先写初步判断，例如“减少店长手工盘点比对的时间”，同时把需要验证的部分放进“待确认事项”，注明由谁确认、确认什么。评审时再决定是否补充基线数据或目标值。把价值写成“提升体验”这类无法判断的表述，会让优先级排序失去依据。
一条用户故事里包含多个角色或多个目标，应该拆开还是合并？
建议拆开。主表一行只写一条故事，角色和目标各自对应一个可独立验收的结果。多个目标塞进同一条，验收标准会互相纠缠，评审时难以判断哪部分算完成。如果几个动作确实属于同一使用场景，可以保留一条主故事，把细分动作写进验收标准子表，逐条列出判断条件。
验收标准要写多少条才算够？
没有固定条数，判断标准是每条都能被独立验证。通常覆盖三类内容即可：正常路径下的结果、关键操作后的输出、异常或边界情况的提示。示例中的三条分别对应列表内容、生成清单和同步延迟提示。如果某条验收标准无法用一句话判断通过与否，说明它还需要拆细或补充验证方式。
模板字段越加越多，团队填写负担重，怎么精简？
先统计字段的实际使用情况：连续几个迭代无人查看、也未影响排期或验收决策的字段，可以改为选填或从模板中移除。只在一两次讨论中出现的信息，放备注即可。精简后保留标题、角色、目标、价值、验收标准、状态这组最小字段集，等协作规模扩大、出现跨团队依赖时再逐步加回。
用户故事模板放在文档里和放在需求管理工具里，有什么使用差别？
放在文档里便于评审时对照阅读和留存讨论记录，适合模板本身的维护与版本回溯；放在需求管理工具里便于跟踪状态、关联依赖和记录验收结果，适合故事进入排期后的推进。两者可以配合使用：模板文档说明填写口径，需求条目承载具体故事。ONES Wiki 的页面模板库可一键创建制式化文档模板，页面版本支持查看与回滚；页面组可关联项目，使需求与文档互相对应。
