用户故事地图通常按“用户活动—用户任务—用户故事”三级展开：横向沿时间或流程排列用户活动，纵向按优先级或发布批次分层。团队首次绘制时，可以直接用一张空白骨架表起步，先铺活动与任务，再补故事和验收要点。本文提供可复制的空白模板、层级说明、必填与选填字段对照，以及一份完整填写示例，范围聚焦模板与结构，不涉及系统架构设计和绘图工具操作。
要点总览（TL;DR）
- 用户故事地图按“用户活动—用户任务—用户故事”三级展开，横向按时间或流程排列活动，纵向按优先级或发布批次分层。
- 首次绘制可直接使用一张七字段骨架表：用户角色、用户活动、用户任务、用户故事、优先级、验收要点、发布批次；最小可用版本可先只填前五项。
- 必填字段是角色、活动、任务、故事和优先级；验收要点与发布批次为选填，可分别在故事评审和排期会上补齐。
- 粒度判断用两个问题检验：一个迭代能否完成，能否写出验收要点；活动列控制在五到八个，超过时考虑拆图。
- 首次绘制后先评审再定稿，字段增删以能否改变团队动作为原则，更新节奏绑定迭代规划与版本发布。
可复制空白模板：用户故事地图骨架表
下面这张表就是首次绘制可以直接使用的骨架。横向看，每一列代表一个用户活动，按用户完成目标的先后顺序从左到右排列；纵向看，同一活动下的任务和故事按优先级从上到下分层。表格用文本形式呈现，复制到文档或表格工具后按列拆开即可。
| 列序号 | 字段 | 填写内容 | 示例占位 |
|---|---|---|---|
| 1 | 用户角色 | 该列活动对应的主要使用者 | （填写角色名称） |
| 2 | 用户活动 | 用户为达成目标而进行的一组行为，横向排列 | （活动A / 活动B / 活动C） |
| 3 | 用户任务 | 活动之下可独立完成的一步 | （任务1 / 任务2） |
| 4 | 用户故事 | 任务之下可交付的最小需求描述 | （作为……我希望……以便……） |
| 5 | 优先级 | 必须 / 应该 / 可以，或数字排序 | （必须） |
| 6 | 验收要点 | 判断故事完成的观察标准 | （可核验的条件） |
| 7 | 发布批次 | 该故事计划进入的版本或批次 | （首批 / 第二批） |
首次绘制的最小可用版本可以只保留四层内容：一行用户活动、每个活动下两到三个用户任务、每个任务下一到两个用户故事，再加一列优先级。验收要点和发布批次可以在骨架确认后再补，避免一开始就陷入细节。填写顺序建议是：先横向写满活动，再纵向补任务，最后落到故事；活动列控制在五到八个，超过时考虑拆成两张地图。
层级结构说明：活动、任务、故事怎么分层
三级层级的核心区别在于回答的问题不同：活动回答“用户要完成哪件大事”，任务回答“这件事分几步做”，故事回答“每一步交付什么”。粒度判断可以用一个简单标准：活动通常跨多个操作步骤，任务在一次使用中能完成，故事则对应一次可验收的交付。
| 层级 | 定义 | 粒度参考 | 常见数量 |
|---|---|---|---|
| 用户活动 | 用户为达成某个目标而进行的一组连续行为 | 跨多个步骤，通常不在一屏内完成 | 每张地图5–8个 |
| 用户任务 | 活动之下可独立完成的一步操作或判断 | 一次使用中可完成 | 每个活动2–5个 |
| 用户故事 | 任务之下可交付、可验收的最小需求单元 | 一个迭代内可完成 | 每个任务1–3个起步 |
| 补充层（可选） | 验收要点、发布批次、依赖关系 | 附着在故事上，不单独成层 | 按需 |
纵向分层有两种常用口径。一种按优先级分“必须、应该、可以”，适合首次绘制时快速区分骨架与锦上添花的内容；另一种按发布批次分“首批、第二批、后续”，适合已经明确版本节奏的团队。两种口径可以并存，但同一张地图内建议只选一种作为主分层，另一种放进字段列，避免纵向含义混乱。
常见拆分误区有三个。第一，把活动写成功能模块名，比如“订单管理”，这更像系统菜单而不是用户行为，应改成“下单并完成支付”这类目标描述。第二，任务拆得过细，把点击按钮、填写单个输入框都列为任务，导致地图变成操作手册。第三，故事写成技术任务，比如“增加缓存层”，用户故事应保留角色、期望和目的三要素，技术实现放到验收要点或任务说明里。粒度拿不准时，用“一个迭代能否完成”和“能否写出验收要点”两个问题检验。
必填与选填字段
模板中的七个字段并非首次绘制都要填满。必填字段保证地图能读、能排序、能交接；选填字段服务于后续排期和评审，可以分批补充。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 用户角色 | 必填 | 没有角色，活动和故事容易变成内部视角；多角色产品需按角色分行或分表 |
| 用户活动 | 必填 | 横向骨架，决定地图的整体范围 |
| 用户任务 | 必填 | 连接活动与故事的中间层，缺失会导致故事悬空 |
| 用户故事 | 必填 | 地图的交付单元，首次绘制至少每个任务写一条 |
| 优先级 | 必填 | 支撑纵向分层和讨论顺序；首次可用“必须/应该/可以”粗分 |
| 验收要点 | 选填 | 骨架确认后补充；进入开发前建议补齐 |
| 发布批次 | 选填 | 已有版本节奏时填写；首次绘制可先留空 |
字段缺失时的处理方式要提前约定。验收要点暂时写不出的故事，标记为“待澄清”，不进入开发队列；发布批次未定的故事，统一放在“未排期”列，评审时再分配。用户角色缺失的地图不建议继续往下拆，因为角色决定了活动的取舍。选填字段的补充时机可以绑定到评审节点：骨架评审补优先级，故事评审补验收要点，排期会补发布批次。
填写示例：一次完整的首次绘制
以下为演示情景，用于说明字段如何配合，不代表真实项目。背景设定：一个面向企业员工的报销工具，首次绘制聚焦“提交报销”这一目标，主要角色为“报销申请人”，辅助角色为“审批人”。地图横向排列三个活动，纵向按“必须/应该/可以”分层。
| 用户角色 | 用户活动 | 用户任务 | 用户故事 | 优先级 | 验收要点 | 发布批次 |
|---|---|---|---|---|---|---|
| 报销申请人 | 准备报销材料 | 收集票据 | 作为申请人，我希望按费用类型上传票据，以便后续归类 | 必须 | 支持常见票据格式，上传后可预览 | 首批 |
| 报销申请人 | 准备报销材料 | 填写费用明细 | 作为申请人，我希望逐条填写金额和事由，以便核对总额 | 必须 | 金额合计自动计算，必填项有提示 | 首批 |
| 报销申请人 | 提交报销单 | 选择审批流 | 作为申请人，我希望按部门自动匹配审批人，以便减少询问 | 应该 | 提交后显示审批路径 | 第二批 |
| 报销申请人 | 提交报销单 | 确认并提交 | 作为申请人，我希望提交前看到完整预览，以便发现遗漏 | 必须 | 预览页包含票据与明细 | 首批 |
| 审批人 | 处理审批 | 查看报销单 | 作为审批人，我希望在一页内看到明细和票据，以便快速判断 | 必须 | 明细与票据同页展示 | 首批 |
| 审批人 | 处理审批 | 退回补充 | 作为审批人，我希望注明退回原因，以便申请人一次改对 | 可以 | 退回原因随通知发送 | 后续 |
示例中层级与优先级的对应关系是：活动本身不标优先级，优先级落在故事上；同一活动下的故事可以分属不同批次，比如“提交报销单”下的“选择审批流”排在第二批，而“确认并提交”进入首批。这样纵向看一列，就能读出该活动在首批交付到什么程度。首次绘制时，每个活动至少保证有一条“必须”级故事，否则说明该活动可能不在本轮范围内，应移到地图边缘或单独成图。
调整与维护方法
首次绘制完成后，地图需要经过一次评审再定稿。评审的重点不是逐条讨论故事细节，而是检查三件事：活动顺序是否符合用户真实流程，每个活动下是否有“必须”级故事支撑，故事粒度是否一致。评审后通常会出现活动合并、任务重排和故事拆分三类修订，修订结果直接更新到同一张表，保留修改记录。
模板字段的增删遵循一个原则：新增字段必须能改变团队的某个动作。比如增加“依赖方”字段，是因为评审时需要据此协调外部团队；增加“澄清状态”字段，是因为待澄清故事需要单独跟踪。反过来，长期无人填写、也不影响排序和交接的字段可以删除，避免表格变宽后难以阅读。字段调整建议在地图评审会上统一决定，不在个人副本上各自修改。
地图的更新节奏可以绑定到需求节奏：每个迭代规划前检查一次，把新发现的故事补进对应任务，把已完成的故事标记状态；每个版本发布后回顾一次，确认发布批次与实际交付是否一致。责任人的常见分工是产品负责人维护活动与优先级，需求分析人员维护任务与故事描述，测试或业务代表补充验收要点。地图作为团队共享文档存放，评审结论和变更原因记录在文档内，方便新成员理解取舍依据。
当团队把地图从文档迁移到协作工具中维护时，可以把每个用户故事对应为一条需求条目，地图文档与需求条目互相引用。ONES Wiki 支持页面组关联项目，需求与文档可以互相对应，页面树能清晰呈现项目文档与知识信息；其页面模板库支持一键创建制式化文档模板，便于把本文的骨架表固化为团队统一格式。文档实时同步并记录页面版本，支持随时查看与回滚，适合承载多轮评审后的地图修订。若团队使用 ONES Assistant，也可以基于项目数据和 Wiki 页面内容提问，辅助查找地图中某条故事的上下文，具体能力以实际开通版本为准。
常见问题
一张用户故事地图上活动太多，应该拆图还是压缩活动数量？
先判断活动是否属于同一个用户目标。如果活动围绕同一目标的不同阶段，比如“提交报销”下的准备材料、提交单据、跟踪进度，可以保留在一张图上，把每个活动下的任务控制在两到三个。如果活动分属不同角色或不同业务目标，比如申请人视角和财务审核视角，建议按角色拆成两张地图，各自维护优先级和发布批次。拆图后在地图标题中注明角色和目标，避免后续评审时混淆范围。
团队对“任务”和“故事”的边界理解不一致，怎么统一？
用可观察的标准对齐：任务是一次使用中能完成的一步，故事是一个迭代内能交付并验收的最小单元。实际操作中，可以让每位参与者在同一活动下各写三条任务和三条故事，评审时逐条对照，把写成操作步骤的条目上移为任务，把需要多次交付才能完成的条目下拆为故事。统一后的判定结果记录在地图文档里，作为后续新成员填写的参照。
验收要点暂时写不出来，故事还能进入开发吗？
建议先标记为“待澄清”，不进入开发队列。验收要点写不出来，通常说明故事的目的或边界还不清楚，此时进入开发容易在实现过程中反复变更。处理方式是在故事评审会上请业务代表或测试人员补充可核验的条件，补齐后再排期。如果某个故事确实需要先做技术验证，可以单独拆出一条验证型任务，与用户故事分开跟踪。
地图画完一次后，后续迭代还要重新画吗？
不需要重画，在同一张表上持续更新即可。常见做法是每个迭代规划前检查一次，把新发现的故事补进对应任务，把已完成的故事标记状态；每个版本发布后回顾一次，核对发布批次与实际交付是否一致。活动层和任务层相对稳定，变化主要发生在故事层。如果业务方向调整导致活动顺序变化，再考虑整体重排或拆图。
把地图放进协作工具维护时，文档和需求条目怎么对应？
一种可行做法是地图文档保留整体结构，每个用户故事对应一条需求条目，两边互相引用。ONES Wiki 支持页面组关联项目，需求与文档可以互相对应，页面树能清晰呈现项目文档与知识信息；页面模板库支持一键创建制式化文档模板，便于把骨架表固化为团队统一格式。文档实时同步并记录页面版本，支持查看与回滚，适合承载多轮评审后的修订。具体能力以实际开通版本为准。
