用户故事模板的填写可以拆成两步：先用“角色—目标—价值”写清谁要什么、为什么，再把验收条件拆成能逐条判断的条目。本文提供一份可直接复制的空白表格，逐字段说明写法，区分必填与选填，并给出一条完整填写示例，方便开发、测试和业务对同一条故事保持一致理解。模板后续也可以放进ONES等协作工具中，通过工作项字段和状态流转固定下来。
要点总览（TL;DR）
- 用户故事模板的核心是“角色—目标—价值”三要素，加验收条件与优先级等辅助字段，先用一句话写清谁、要什么、为什么。
- 验收条件要拆成可逐条判断的条目，每条包含前提、操作和可观察结果，避免“界面友好”这类无法验证的描述。
- 角色、目标、价值、验收条件、故事标题为必填；估算、关联需求、负责人、备注可按阶段选填，早期探索阶段可先精简。
- 填写顺序建议先写三要素，再补验收条件，最后填优先级、估算和状态，保证开发、测试和业务理解一致。
- 模板需按项目类型增减字段并定期评审，把字段配置到协作工具的工作项类型中，可让填写与状态流转保持一致。
可复制空白用户故事模板
下面两张表构成一套最小可用的用户故事模板。主表记录故事本身，验收条件子表记录“做到什么程度算完成”。复制到文档或表格工具后，把空单元格逐项填写即可；一条故事对应一行主表，对应多行验收条件。
用户故事主表
| 字段 | 填写内容 |
|---|---|
| 故事编号 | |
| 故事标题 | |
| 角色 | |
| 目标 | |
| 价值 | |
| 验收条件 | 见验收条件子表 |
| 优先级 | |
| 估算 | |
| 状态 | |
| 关联需求 | |
| 负责人 | |
| 备注 |
验收条件子表
| 序号 | 场景/前提 | 操作 | 预期结果 | 是否已验证 |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 |
如果团队使用在线表格，可以把两张表放在同一工作表的不同区域，用故事编号关联；如果使用需求管理工具，主表对应一个工作项，验收条件对应子任务或检查项。模板本身只规定字段，不规定工具。
每个字段写什么：字段说明
字段说明的作用是让不同的人填同一条故事时口径一致。下面按“三要素—验收条件—辅助字段”的顺序解释，每个字段给出写法要点和常见问题。
角色、目标、价值三要素
三要素可以用一句话串起来：“作为〔角色〕，我希望〔目标〕，以便〔价值〕。”这句话是故事的主干，其余字段都是补充。
- 角色：写具体的使用者或受影响方，例如“首次注册的企业管理员”“每月对账的财务专员”。避免只写“用户”“系统”，角色越具体，后续讨论越容易聚焦。
- 目标：写角色想完成的操作或想获得的能力，用动词开头，例如“批量导入成员名单”“按项目导出工时报表”。目标描述“要什么”，不写实现方式。
- 价值：写这个目标带来的业务结果或使用收益，例如“减少手工录入错误”“让月度结算提前两天完成”。价值要能回答“为什么值得做”，避免写成“提升体验”这类无法判断的表述。
验收条件字段
验收条件回答“怎样算做完”，每条应当可以被独立判断为通过或不通过。推荐写成“前提—操作—预期结果”的结构，或使用“假如……当……那么……”的句式。判断标准包括：有明确的输入或前置状态、有可执行的操作、有可观察的结果。像“界面友好”“响应较快”这类描述无法验证，应改成具体阈值或可观察现象，例如“列表在 200 条数据内一次加载完成”。验收条件数量不固定，覆盖主要正常流程和关键异常分支即可。
优先级、估算、状态与关联需求
- 优先级：标明这条故事在当前迭代或需求池中的相对顺序，可用高/中/低或数字排序。优先级服务于排期决策，填写时应说明判断依据，例如依赖关系、客户承诺时间。
- 估算：记录团队对工作量的相对估计，单位可以是故事点、人天或理想小时，同一项目内保持口径一致。估算在团队讨论后填写，不由单人拍定。
- 状态：反映故事当前所处环节，例如待澄清、已就绪、开发中、待验收、已完成。状态让协作方知道下一步该谁动作。
- 关联需求：填写这条故事所属的上级需求、史诗或业务目标编号，便于回溯“为什么做这件事”。
- 负责人与备注：负责人写当前推进人；备注记录待确认问题、决策记录或拆分说明。
必填与选填：哪些字段不能空
模板字段齐全不等于每条都要填满。必填字段保证故事可被理解和验收，选填字段服务于排期和协作。团队规模小、沟通频繁时，可以只保留必填项；跨团队协作或需求量大时，再逐步补充辅助字段。
| 字段 | 建议 | 理由与适用场景 |
|---|---|---|
| 角色 | 必填 | 没有角色，故事无法判断为谁而做 |
| 目标 | 必填 | 故事的核心内容，缺失则无法开发 |
| 价值 | 必填 | 支撑优先级判断，避免做无收益的功能 |
| 验收条件 | 必填 | 测试和验收的依据，至少一条 |
| 故事标题 | 必填 | 用于列表展示和检索 |
| 优先级 | 建议必填 | 进入排期前必须有相对顺序 |
| 状态 | 建议必填 | 协作方据此判断下一步动作 |
| 估算 | 选填 | 进入迭代规划时填写；早期探索阶段可暂缺 |
| 关联需求 | 选填 | 需求层级较深或需要回溯时填写 |
| 负责人 | 选填 | 故事进入开发后指定 |
| 备注 | 选填 | 有未决问题或特殊约定时填写 |
字段过多时，可以按“能否帮助判断做不做、怎么做、做完没有”三个问题精简：与判断无关的字段移到备注或删除。另一个常见做法是分两级模板——需求池阶段只填三要素和优先级，进入迭代前再补齐验收条件、估算和负责人。这样既保留信息完整性，也避免早期填写负担过重。
完整填写示例：一条用户故事从空白到可用
下面用一条“批量导入成员”的故事示范填写结果，字段与前面的模板一一对应。示例场景为演示用途，数字和名称仅用于说明写法。
| 字段 | 填写内容 |
|---|---|
| 故事编号 | US-014 |
| 故事标题 | 企业管理员批量导入成员名单 |
| 角色 | 刚完成企业注册的管理员 |
| 目标 | 通过上传表格一次导入全部成员，并自动分配所属部门 |
| 价值 | 避免逐个手工添加，减少录入错误，让团队当天就能开始使用 |
| 验收条件 | 见下方验收条件子表 |
| 优先级 | 高（首批客户上线依赖此功能） |
| 估算 | 5 故事点 |
| 状态 | 已就绪 |
| 关联需求 | REQ-003 企业成员管理 |
| 负责人 | 张明 |
| 备注 | 导入模板格式待与客户成功团队确认 |
| 序号 | 场景/前提 | 操作 | 预期结果 | 是否已验证 |
|---|---|---|---|---|
| 1 | 管理员已登录且拥有成员管理权限 | 上传符合模板格式的 50 人名单 | 50 人全部创建成功，页面显示成功数量 | 否 |
| 2 | 名单中有一行邮箱格式错误 | 执行导入 | 该行被跳过并提示行号与原因，其余行正常导入 | 否 |
| 3 | 名单中邮箱与已有成员重复 | 执行导入 | 重复行不重复创建，结果中标注“已存在” | 否 |
| 4 | 上传文件超过 1000 行 | 执行导入 | 提示超出单次上限，并说明分批导入方式 | 否 |
对照字段说明可以看到：角色写的是具体状态下的管理员，目标用动词描述操作，价值落到“当天开始使用”这一可感知结果；验收条件每条都有前提、操作和可观察结果，测试人员可以逐条勾选“是否已验证”。备注保留了待确认事项，避免在故事里埋下未决问题。
模板的调整与维护方法
模板用久了容易出现两种问题：字段越加越多，填写变成负担；或者长期不更新，和实际流程脱节。维护的重点是让字段跟着项目类型和团队协作方式变化，而不是一次定死。
按项目类型增减字段
面向外部客户交付的项目，通常需要保留客户编号、承诺时间等字段；内部工具类项目可以精简为三要素加验收条件。涉及合规或审批的场景，可以增加“审批状态”“合规检查项”。调整时遵循一个原则：新增字段要能对应一个具体决策或动作，否则放入备注即可。每次调整后，用一条历史故事回填验证，确认新字段确实被使用。
模板版本与评审机制
给模板标注版本号和生效日期，修改记录写明“增加了什么字段、解决什么问题”。可以每季度或每个项目复盘时评审一次，收集填写者的反馈：哪些字段经常空着、哪些字段反复引发追问。评审结论落到模板文档中，并在团队内同步，避免不同项目各用一套互不兼容的表格。
在协作工具中落地模板
模板固定在文档里，执行时仍可能走样。把字段配置到协作工具的工作项类型中，可以让填写和流转保持一致。以ONES为例，可以在工作项类型里配置角色、目标、价值、优先级、估算等字段，把验收条件设为检查项或子工作项，并用状态流承载“待澄清—已就绪—开发中—待验收—已完成”的流转；字段必填规则和状态流转条件可以在配置中约束，模板调整时同步修改工作项配置即可。这样，空白表、字段说明和实际执行使用同一套结构，评审时也能直接查看每条故事的验收条件完成情况。
常见问题
用户故事模板里的验收条件写几条合适？
数量没有固定标准，覆盖主要正常流程和关键异常分支即可。一条故事通常对应 3–5 条验收条件，复杂故事可以更多。判断标准是每条都能被独立验证为通过或不通过；如果某条验收条件需要再拆成多个判断，说明它还不够具体，应继续拆分。
小团队字段填不全，可以只用三要素吗？
可以。团队规模小、沟通频繁时，先保留角色、目标、价值、故事标题和至少一条验收条件，就能支撑开发和验收。优先级和状态在进入排期前补上；估算、关联需求、负责人可以在故事进入迭代或开发阶段再填。字段精简的前提是团队对“做完的标准”有共识，验收条件不能省。
一条大需求拆成多条用户故事后，模板怎么关联？
在每条故事的主表里填写同一个“关联需求”编号，指向所属的上级需求或史诗；验收条件子表按故事分别填写，不混在一起。这样回溯时既能看清单条故事的完成情况，也能汇总上级需求的整体进度。拆分后如果发现某条故事仍然过大，可以继续拆，并在备注中记录拆分说明。
模板放进协作工具后，还需要维护文档版本吗？
需要。工具中的字段配置是执行层，文档模板是说明层，两者要保持一致。建议在文档中标注模板版本号和生效日期，修改记录写明增减了哪些字段、解决什么问题；工具里的工作项字段和必填规则同步调整。评审时对照文档检查工具配置，避免出现文档写一套、实际填另一套的情况。
验收条件里的“是否已验证”由谁填写？
通常由执行验收的测试人员或产品负责人在验收环节填写，开发人员在提测前可以先自检。这个字段的作用是让协作方一眼看到哪些条件已经确认、哪些还没覆盖。如果团队在协作工具中把验收条件设为检查项，勾选动作本身就记录了验证状态，不需要再单独维护一列。
