扁平待办事项列表是按优先级排序的列表。它告诉您接下来要构建什么，但不显示各部分如何组合在一起，并且容易发布十个精致但无法构成用户可完成整体体验的功能。用户故事地图通过将故事沿用户旅程排列来解决这个问题，使您能够看到整个产品并裁剪出一个从头到尾可用的首次发布版本。
本指南介绍如何构建故事地图，如何将最顶层的切片转化为 MVP 范围，如何使用 INVEST 原则检查每个故事，以及将大型故事拆分为冲刺规模故事的拆分模式。如果您需要先了解基础知识，请从 如何编写用户故事.
什么是用户故事地图
故事地图由 Jeff Patton 提出，最早见于 2005 年的一篇文章《It's all in how you slice it》，随后在 2008 年的帖子 The new user story backlog is a map中进一步阐述，后来收录于其著作《User Story Mapping》（O'Reilly, 2014）。另请参阅他的 故事地图资源 以及 Agile Alliance 术语表条目.
地图有两个方向：
- 从左到右是叙事：用户按顺序经历的主要活动，以及每个活动内部的步骤。这一行被称为主干。
- 从上到下是优先级和细节：在每个步骤下方，是使其成为可能的故事，最核心的故事位于顶部，替代方案、边缘情况和锦上添花的功能位于下方。
地图上的水平线将其划分为发布切片。第一条线上方的所有内容构成第一个发布版本；它应覆盖主干中的每一项活动，即使覆盖得很薄。
构建故事地图的 6 个步骤
您可以在墙上使用便利贴，或在数字白板上进行。邀请决定范围的人员和负责构建的人员：产品、设计、至少一名开发人员，理想情况下还包括一位经常与客户沟通的人。对于小型产品，首次绘制地图通常需要一个几小时的工作会议。
1. 界定问题
写下产品的目标用户、它解决的问题，以及能表明第一个发布版本成功的结果。将其概括为三句话，置于地图顶部。后续所有的取舍都以此结果为准。
2. 绘制主干
问“用户首先做什么，然后做什么？”，并将每个活动写在一张卡片上，从左到右排列。使用动词：例如“找到遛狗人”，而不是“搜索”。然后将每个活动分解为步骤。边做边大声讲述故事；当有人问“等等，他们是怎么到这里的？”时，缺口就会显现出来。
3. 探索细节
在每个步骤下方，添加使其可行的故事：选项、替代方案、错误情况、管理需求。此时不要进行筛选。这是地图发挥价值之处，因为当人们能一次性看到整个旅程时，会注意到缺失的部分。
4. 寻找行走骨架
行走骨架（Alistair Cockburn 提出的术语）是能够端到端运行的最精简版本产品。在每个步骤下，挑选出用户不可或缺的那一个故事，并将其移至顶部。如果某个步骤没有核心内容，请询问它是否真的属于主干。
5. 划分发布切片
画水平线将故事分组为发布版本。为每个切片命名，名称应陈述结果，例如“主人可以预订并支付一次遛狗”，而不是“发布 1”。每个切片应能独立使用，并回答您关于产品的一个疑问。
6. 规划第一个切片并保持地图的活力
为第一个切片中的故事编写验收标准（我们的 用户故事模板 有三种格式），用 INVEST 原则检查每一个，拆分过大的故事，并将它们移入冲刺待办列表。保持地图可见，并在每次发布后更新它；它是一个规划工具，而非一次性工作坊的产物。
示例：遛狗应用的故事地图
这是一个连接狗主人和当地遛狗人的市场平台的精简地图。列代表主干；每一行代表一个发布切片。
| 切片 | 注册 | 寻找遛狗人 | 预订遛狗 | 支付 | 遛狗期间 | 遛狗后 |
|---|---|---|---|---|---|---|
| 最小可行产品（MVP）骨架 | 使用电子邮件注册；添加一只狗 | 查看邮政编码附近的已批准遛狗员列表 | 请求时间段；遛狗员通过电子邮件接受 | 预订时刷卡支付 | 遛狗员标记遛狗开始和结束 | 主人收到摘要消息 |
| 版本 2 | 使用 Google 或 Apple 登录；多只狗 | 按价格和可用性筛选；带照片的遛狗员个人资料 | 应用内接受和拒绝；提醒 | 保存的卡片；取消时自动退款 | 地图上的实时位置 | 评分和评论 |
| 后续版本 | 推荐码 | 收藏的遛狗员 | 每周定期预订 | 订阅和小费 | 遛狗期间的照片更新 | 一键重新预订 |
注意骨架中遗漏的内容：没有实时追踪，没有评论，没有应用内消息，且遛狗员审批是手动进行的。但主人仍然可以从注册到完成并支付一次遛狗服务，这足以测试人们是否愿意预订陌生人来遛他们的狗。
地图如何转化为 MVP 范围
良好地图的最顶层切片就是你的 MVP 范围。在确定之前，请使用以下检查项：
- 它涵盖主干中的每项活动。一个允许人们预订但不允许支付的产品不是 MVP；它只是半个演示。
- 它服务于一个主要用户和一个主要旅程。次要角色（管理员、合作伙伴）只需获得维持旅程运行的最低限度支持，通常是一个电子表格或手动步骤。
- 它测试一个具体的假设。在切片旁边写下它回答的问题，例如“主人是否会在见面前向遛狗员支付费用？”
- 允许后台进行手动工作。对于首批用户，手动审批遛狗员或自行发送摘要是可以的，这能告诉你哪些环节值得自动化。
- 它符合你的预算和时间表。如果不符合，请在每个列内削减故事（使用以下模式进行拆分），而不是删除整个列。
对于没有技术联合创始人的创始人来说，地图也是你可以交给开发团队的最有用文档：它在一页中展示了整个产品、首个发布版本以及削减背后的理由。我们的指南 非技术创始人如何构建 MVP 涵盖了接下来该怎么做。
INVEST 检查清单
一旦故事被放在地图上，请根据 INVEST 原则检查第一个切片中的每个故事，该首字母缩略词由 Bill Wake 在 2003 年的 《INVEST 于好故事，SMART 任务》中提出.
| 字母 | 含义 | 要问的问题 | 如果失败 |
|---|---|---|---|
| I | 独立 | 我们能否在不等待其他故事的情况下构建并发布此故事？ | 合并紧密耦合的故事，或重新拆分，使每个故事都能独立交付 |
| N | 可协商 | 解决方案是否仍开放讨论？ | 从故事中移除实现细节；将其保留在备注中 |
| V | 有价值 | 如果发布此功能，用户或业务方会注意到吗？ | 将技术任务合并到其所服务的用户故事中 |
| E | 可估算 | 团队是否具备足够的信息来估算工作量？ | 执行一个限时探索（spike），或提出阻碍估算的问题 |
| S | 小 | 它是否能轻松容纳在一个冲刺（sprint）中？ | 使用以下模式之一进行拆分 |
| T | 可测试 | 我们能否编写可判定通过或失败的验收标准？ | 用可观察的结果替换模糊的词语（如“快速”、“简单”） |
独立性是最难完全满足的标准，将其视为目标而非规则是可以接受的。小而可测试是应当严格执行的标准。
如何拆分用户故事
垂直拆分故事：每个部分都应通过系统的每一层交付用户可见的价值。按层拆分（“构建数据库”、“构建 API”、“构建界面”）会产生在全部完成前无法交付任何价值的部分，这违背了拆分的初衷。这些模式收集在 《Humanizing Work》用户故事拆分指南 中，由 Richard Lawrence 和 Peter Green 编写，涵盖了大多数情况。
工作流步骤
将多步骤流程拆分为各个步骤，或先构建简单的端到端版本，稍后再添加步骤。“预约遛狗”变为：请求时段；遛狗员接受；主人收到确认。后续：遛狗员提议其他时间。
业务规则变体
如果故事包含多个规则，先发布最常见的规则。“取消退款”变为：提前 24 小时取消全额退款；24 小时内部分退款；遛狗开始后不退款。
数据变体
从一种数据类型开始，再添加其他类型。“按位置搜索”变为：按邮政编码搜索；然后按当前位置搜索；然后在地图上绘制区域搜索。
先处理正常路径，再处理异常路径
先构建主要成功路径，然后将失败情况作为独立故事处理，按发生频率和造成的损害程度排序。“刷卡支付”变为：支付成功；卡片被拒；支付提供商不可用。
操作
“管理狗狗”隐藏了创建、查看、编辑和删除操作。通常首次发布只需创建和查看功能。
界面或平台变体
先在一个平台或一种输入方式上发布。如果首批用户允许，先做 Web 端再做移动端，或先做英语再做其他语言。
先做简单版本，延后性能优化
先让它运行，再让它变快。对于试点城市，加载 50 个遛狗员列表耗时 3 秒是可以接受的；当数据量证明有必要时，再作为独立故事进行优化。
探索（Spike）
当故事因未知因素（如“我们能否在两种手机平台上获取后台实时位置？”）而无法估算时，拆分出一个短时间的限时调查。探索的输出是知识和更准确估算的故事，而非已发布的功能。
SPIDR：简短的记忆口诀
Mike Cohn 将主要拆分技术归纳为 SPIDR 缩写：Spikes（探索）、Paths（路径）、Interfaces（界面）、Data（数据）和 Rules（规则）（五种简单但强大的用户故事拆分方法）。如果故事太大且不确定从何入手，请按此顺序依次尝试这五种方法。
| 技术 | 拆分依据 | 示例 |
|---|---|---|
| 探索（Spikes） | 先研究未知因素 | 在估算实时跟踪功能前，进行为期两天的后台位置探索 |
| 路径 | 故事中的替代路径 | 现在用卡支付，稍后用钱包支付 |
| 接口 | 设备、浏览器或接口类型 | 所有者先通过网页预订，其次通过移动应用 |
| 数据 | 数据类型或范围 | 首次每次预订一只狗；后续支持多只狗 |
| 规则 | 业务规则，初期可放宽 | 试点阶段无取消规则；退款政策作为独立故事 |
故事映射常见错误
- 映射功能而非用户活动。以“登录、仪表盘、设置”为主干描述的是界面，而非用户旅程。
- 首个切片仅深入一列。在预订功能存在之前完善注册流程，会导致无内容可供测试。
- 让映射图过于详细。若已在墙上编写验收标准，则已从映射阶段转入细化阶段。
- 映射时缺少开发人员参与。未由开发人员参与绘制的切片，往往在顶部隐藏高成本故事。
- 将映射图视为最终定稿。每次发布后，应将所学内容更新至映射图，并重新切割下一个切片。
如需查看可适配至自身映射图的规范故事，请参阅我们的 用户故事示例.
故事映射工具
在首次全员同地会议中，墙面与便利贴仍效果最佳。对于远程团队，Miro 和 FigJam 等通用白板提供故事映射模板，而 StoriesOnBoard 等专用工具可将映射图与待办事项追踪器同步。Jira 等追踪器可按史诗分组展示故事，从而呈现主干，但通常需借助插件或白板才能查看发布切片。请选择团队会持续使用的工具；若无人更新，映射图在一两个冲刺周期内便会失去效用。
常见问题
什么是用户故事映射？
由 Jeff Patton 提出的一种技术，用于将用户故事沿用户旅程（主干，从左至右）及优先级（从上至下）排列。水平线将映射图划分为发布切片，使团队能够规划端到端可用的发布版本。
故事映射图与产品待办事项列表有何区别？
待办事项列表是按优先级排序的单列清单。故事映射图以两个维度展示相同故事：用户活动与优先级，从而直观呈现故事间的关联性及发布版本是否覆盖完整旅程。
什么是行走骨架？
产品最精简但可端到端运行的版本，在旅程每个步骤下仅包含一个核心故事。该术语源自 Alistair Cockburn；在故事映射图中，通常对应首个发布切片。
INVEST 代表什么？
独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小（Small）且可测试（Testable）。Bill Wake 于 2003 年提出此概念，作为优质用户故事的检查清单。
用户故事应多小？
小到团队能在一个冲刺周期内完成、测试并演示，理想情况下仅需数日。若故事常需整个冲刺周期才能完成，则应拆分。
什么是 SPIDR？
Mike Cohn 描述的五个故事拆分技术：探针（Spikes）、路径（Paths）、接口（Interfaces）、数据（Data）与规则（Rules）。
谁应参与故事映射会议？
决定范围的人员与负责构建的人员：产品负责人或创始人、设计师、至少一名开发人员，以及理想情况下能与客户沟通的人员，如客服或销售。
已有映射图或仅有初步构想，需构建首个切片？我们可协助您确定端到端可用的 MVP 范围，并以短冲刺周期交付。详见 我们的月度开发计划.