user-story-mapping-workshop

目的

通过针对系统、用户、工作流和优先级提出适应性问题，引导产品经理创建用户故事地图，然后生成一个包含主干（活动）、用户任务和发布切片的二维地图。利用它将扁平的待办列表转化为可视化故事地图，传达整体愿景、发现缺失的功能，并支持有意义的发布规划，避免故事脱离整个系统叙事，变成“脱离上下文的杂烩”。

这不是待办列表生成器，而是一个可视化沟通框架，按用户工作流（横向）和优先级（纵向）组织工作。

输入

最适合提供： 要绘制地图的系统或工作流。 也有帮助： 主要用户、已知的工作流步骤，以及地图需要协助做出的决策（MVP 范围、发布计划）。

通过调用本身提供的任何内容——技能名称后面的文本、粘贴的上下文信息，或附加的 ARGUMENTS: 行——都视为已给出的答案。使用这些信息，并跳过其中已涵盖的问题；不要重复提问。

没有准备任何信息也没关系。 工作坊会先询问系统及其用户（Q1），然后按照引导流程继续进行。

调用示例： Run a story mapping workshop for our vendor onboarding portal — output should give us a first release slice.

核心概念

什么是用户故事地图？

故事地图（Jeff Patton）以两个维度组织用户故事：

横轴（从左到右）： 按叙事／工作流顺序排列的活动，即向他人介绍系统时会采用的顺序

纵轴（从上到下）： 每项活动中的优先级，最重要的任务排在最上方

结构：

Backbone (Activities across top)
↓
User Tasks (descending vertically by priority)
↓
Details/Acceptance Criteria (at the bottom)

核心原则

主干： 核心活动构成系统的结构核心；它们之间不进行优先级排序，而是共同组成叙事流程。

行走骨架： 所有活动中优先级最高的任务共同构成最小可行产品，即最小的端到端功能集合。

肋骨： 各项活动下方垂直排列的支持性任务，通过位置体现优先级。

从左到右、从上到下的构建策略： 跨所有主要功能增量构建，而不是先完整完成一项功能，再开始另一项。

这种方法为何有效

• 可视化沟通： 故事地图作为信息展示板持续呈现，让大家始终关注全局
• 叙事结构： 按用户工作流组织，而非按技术架构组织
• 发布规划： 横向切片揭示 MVP 和增量发布方案
• 发现缺口： 揭示扁平待办列表难以显现的缺失功能

反模式（这不是什么）

• 不是甘特图： 故事地图展示优先级，而非时间估算
• 不是技术架构： 地图遵循用户工作流，而非系统层次（UI → API → DB）
• 不是项目计划： 它是用于探索和沟通的工具，而非时间安排表

适用场景

• 开始开发新产品或重大功能
• 重新梳理现有待办列表（从扁平列表转为可视化地图）
• 让利益相关者就范围和优先级达成一致
• 规划 MVP 或增量发布

不适用场景

• 单一功能项目（使用故事地图过于繁琐）
• 待办列表已经清晰且优先级明确
• 技术重构工作（没有可绘制的用户工作流）

---

促进流程的事实依据

将 workshop-facilitation 作为此技能的默认交互协议。

其中定义了：

• 会话提示 + 进入模式（引导式、上下文倾倒、最佳猜测）
• 每轮一个问题，并使用通俗易懂的提示
• 进度标签（例如，Context Qx/8 和 Scoring Qx/5）
• 中断处理以及暂停／恢复行为
• 在决策点提供编号建议
• 为常规问题提供编号快速选择选项（适用时包括 Other (specify)）

此文件定义了特定领域的评估内容。如有冲突，请遵循此文件的领域逻辑。

应用

此交互式技能会提出最多 5 个自适应问题，每步提供 3-4 个编号选项。

使用 template.md 获取引导议程和输出检查清单。

交互模式：当你希望逐步进行，并在决策点提供编号建议、为常规问题提供快速选择选项时，搭配 skills/workshop-facilitation/SKILL.md 使用。如果用户要求一次性输出，请跳过多轮引导。

---

步骤 0：收集上下文（提问前）

Agent 建议：

在创建故事地图之前，我们先收集一些上下文：

产品／功能上下文：

• 你要绘制哪个系统或功能的地图？
• 产品概念、PRD 草稿或现有待办事项列表
• 网站文案、定位材料或用户流程
• 现有用户故事（从扁平待办事项列表过渡时）

用户上下文：

• 目标用户画像或用户群体
• 用户研究、访谈或旅程地图
• 待完成的工作或问题陈述

你可以直接粘贴这些内容，也可以简要描述该系统。

---

问题 1：确定范围

Agent 提问： “你要绘制什么的地图？（范围是什么？）”

提供 4 个编号选项：

1. 整个产品 — “从发现到完成的完整端到端系统”（适用于新产品或全面重写）
2. 主要功能领域 — “大型产品中的特定工作流（例如‘引导流程’、‘结账’、‘报告’）”（适用于功能发布）
3. 用户旅程 — “特定用户目标或待完成的工作（例如‘雇用承包商’、‘报税’）”（适用于以 JTBD 为驱动的地图绘制）
4. 重新设计／重构 — “正在重建或简化的现有产品／功能”（适用于旧系统现代化）

或者描述你的具体范围。

用户回复：[选择或自定义]

---

问题 2：确定用户／用户画像

Agent 提问： “这张地图面向哪些主要用户？（列出用户画像或用户群体。）”

提供 4 个编号选项：

1. 单一用户画像 — “一种主要用户类型（例如‘小企业主’）”（简化地图绘制，适合 MVP）
2. 多个用户画像，共享工作流 — “不同用户类型执行相同的核心活动（例如，‘买家’和‘卖家’都会浏览商品列表）”（适用于市场平台）
3. 多个用户画像，不同工作流 — “不同用户类型有各自独特的工作流（例如‘管理员’与‘最终用户’）”（需要单独绘制地图或使用泳道）
4. 组织内的角色 — “不同的职能岗位（例如‘PM’、‘设计师’、‘工程师’）”（适用于内部工具）

或者描述你的用户。

**自适应：**使用步骤 0 提供的上下文中的用户画像（初步用户画像、JTBD 等）。

用户回复：[选择或自定义]

---

问题 3：生成主干（活动）

Agent 表示： “我们来构建主干——用户为实现目标而执行的活动叙事流程。”

Agent 根据范围（Q1）和用户（Q2），生成 5-8 个活动，并按照工作流顺序从左到右排列。

示例（如果范围 =“电子商务结账”）：

Backbone Activities (left to right):

1. Browse Products
2. Add to Cart
3. Review Cart
4. Enter Shipping Info
5. Enter Payment Info
6. Confirm Order
7. Receive Confirmation

Agent 提问： “这个主干是否涵盖了完整的工作流？需要添加、删除或重新排序活动吗？”

用户回复：[批准、修改或添加自定义活动]

---

问题 4：生成用户任务（置于每项活动下方）

Agent 说： “现在，我们在每项活动下方添加用户任务，并按优先级排列（最上方 = 必须具备，最下方 = 有则更好）。”

Agent 为每项活动生成 3-5 项用户任务，并按优先级从上到下排列。

示例（活动 2：“加入购物车”）：

Add to Cart (Activity)
├─ Add single item to cart (must-have, walking skeleton)
├─ Adjust quantity (must-have)
├─ Add multiple items at once (should-have)
├─ Save item for later (nice-to-have)
└─ Add gift wrapping (nice-to-have)

Agent 对所有主干活动重复此操作，展示完整的地图。

Agent 询问： “这些任务是否涵盖了关键内容？优先级是否正确（最上方 = MVP，最下方 = 后续版本）？”

用户回应： [批准、修改或添加自定义任务]

---

问题 5：确定发布切片（步行骨架 + 增量）

Agent 说： “我们通过在地图上画水平线来定义发布切片。”

Agent 生成 3 个发布切片：

发布 1（步行骨架）： 所有活动中优先级最高的任务——最精简的端到端功能

发布 2（下一个增量）： 增强核心工作流的第二优先级任务

发布 3（完善/扩展）： 第三优先级任务（锦上添花的功能、边缘情况、优化）

示例：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 1 (Walking Skeleton):
- Browse products (basic list view)
- Add single item to cart
- Review cart (line items + total)
- Enter shipping info (name, address)
- Enter payment info (credit card only)
- Confirm order (basic confirmation)
- Receive email confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 2 (Enhanced):
- Product filtering/search
- Adjust quantity in cart
- Save for later
- Multiple shipping options
- Multiple payment methods
- Order tracking link
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 3 (Polish):
- Product recommendations
- Guest checkout
- Gift wrapping
- Promo codes
- Advanced payment options
- Post-purchase surveys
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Agent 询问： “这些发布切片是否合理？是否应该调整范围或优先级？”

用户回应： [批准或修改]

---

输出：用户故事地图

完成整个流程后，Agent 输出：

# User Story Map: [Scope from Q1]

**Users:** [From Q2]
**Date:** [Today's date]

---

## Backbone (Activities)

[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5] → [Activity 6]

---

## Full Story Map

### [Activity 1: Name]
- **[Task 1.1]** — Must-have (Release 1)
- **[Task 1.2]** — Should-have (Release 2)
- **[Task 1.3]** — Nice-to-have (Release 3)

### [Activity 2: Name]
- **[Task 2.1]** — Must-have (Release 1)
- **[Task 2.2]** — Should-have (Release 2)
- **[Task 2.3]** — Nice-to-have (Release 3)

[...repeat for all activities...]

---

## Release Slices

### Release 1: Walking Skeleton (MVP)
**Goal:** Minimal end-to-end functionality

**Stories:**
- [Task 1.1] — [Activity 1]
- [Task 2.1] — [Activity 2]
- [Task 3.1] — [Activity 3]
- [Task 4.1] — [Activity 4]
- [Task 5.1] — [Activity 5]
- [Task 6.1] — [Activity 6]

**Why this is the walking skeleton:** Delivers complete workflow with simplest version of each activity.

---

### Release 2: Enhanced Functionality
**Goal:** Improve core workflow with priority enhancements

**Stories:**
- [Task 1.2] — [Activity 1]
- [Task 2.2] — [Activity 2]
- [Task 3.2] — [Activity 3]
[...]

---

### Release 3: Polish & Expansion
**Goal:** Nice-to-haves, edge cases, optimizations

**Stories:**
- [Task 1.3] — [Activity 1]
- [Task 2.3] — [Activity 2]
[...]

---

## Next Steps

1. **Refine stories:** Use `skills/user-story/SKILL.md` to write detailed stories with acceptance criteria
2. **Estimate effort:** Score stories (story points, t-shirt sizes)
3. **Validate with stakeholders:** Walk through map left-to-right, confirm priorities
4. **Display map:** Print/post as information radiator for ongoing reference

---

**Ready to write user stories? Let me know if you'd like to refine the map or break down specific stories.**

---

示例

示例 1：优秀的用户故事地图（电子商务结账）

Q1 回应：“主要功能领域——电子商务结账工作流”

Q2 回应：“单一角色——网购者”

Q3 - 生成的主干：

Browse → Add to Cart → Review Cart → Enter Shipping → Enter Payment → Confirm → Receive Confirmation

Q4 - 生成的用户任务：

Browse Products
├─ View product list (R1)
├─ Search/filter (R2)
└─ Product recommendations (R3)

Add to Cart
├─ Add single item (R1)
├─ Adjust quantity (R2)
└─ Save for later (R3)

Review Cart
├─ View line items + total (R1)
├─ Apply promo code (R2)
└─ Estimate shipping cost (R3)

[...etc...]

Q5 - 发布切片：

• **发布 1：**步行骨架——不含额外功能的基本流程
• **发布 2：**搜索、调整数量、促销码
• **发布 3：**推荐、访客结账、礼品选项

这样做有效的原因：

• 主干遵循用户叙事（而非技术层次）
• 步行骨架提供端到端价值
• 增量发布在不破坏核心流程的前提下增加功能

---

示例 2：糟糕的用户故事地图（技术层次）

主干（错误）：

UI Layer → API Layer → Database Layer → Deployment

这样做行不通的原因：

• 以用户为中心的程度不足（用户并不关心技术架构）
• 无法通过增量方式交付端到端价值
• 只是伪装成故事地图的瀑布式思维

改进方法：

• 按用户工作流绘制地图：“注册 → 配置设置 → 邀请团队 → 启动项目”
• 每次发布都交付完整工作流，而非单个层次

---

常见陷阱

陷阱 1：伪装成地图的扁平待办事项列表

**症状：**故事地图只是垂直列表，没有横向叙事

**后果：**失去沟通价值；仍然是“脱离上下文的杂乱内容”

**改进方法：**强制采用横向结构——活动横向排列在顶部，任务从上到下排列

---

陷阱 2：将技术架构作为主干

**症状：**主干 = “前端 → 后端 → 数据库”

**后果：**以用户为中心的程度不足，无法通过增量方式交付价值

**改进方法：**主干应遵循用户工作流，而非系统层次

---

陷阱 3：功能完整的瀑布式开发

**症状：**发布 1 = “完整构建活动 1”，发布 2 = “完整构建活动 2”

**后果：**所有活动完成之前都无法提供端到端价值

**改进方法：**步行骨架 = 横跨所有活动的精简切片，并通过增量逐步增强

---

陷阱 4：过早添加过多细节

**症状：**试图预先梳理每种边缘情况和验收标准

**后果：**陷入分析瘫痪，丢失全局视角

**改进方法：**从主干和高层级任务开始，之后再细化

---

陷阱 5：地图隐藏在工具中

**症状：**故事地图放在 Jira/Miro 中，从不展示

**后果：**失去其作为信息辐射器的价值

**改进方法：**将地图打印出来或张贴出来；让团队每天都能看到

---

参考资料

相关技能

• skills/user-story-mapping/SKILL.md — 包含故事地图模板的组件技能
• skills/user-story/SKILL.md — 将地图中的任务转换为详细的用户故事
• skills/proto-persona/SKILL.md — 定义用于绘制地图的用户
• skills/jobs-to-be-done/SKILL.md — 为主干活动提供参考

外部框架

• Jeff Patton，《User Story Mapping》（2014）——故事地图框架的起源
• Jeff Patton，“The New User Story Backlog is a Map”（博客）——阐释主干概念

Dean 的作品

• [如果 Dean 有故事地图相关资源，请在此处添加链接]

来源

• 改编自 skills/user-story/SKILL.md、skills/user-story-splitting/SKILL.md 和 skills/user-story-mapping/SKILL.md。

---

**技能类型：**交互式 建议文件名： user-story-mapping-workshop.md 建议位置： /skills/interactive/ **依赖项：**使用 skills/user-story-mapping/SKILL.md、skills/user-story/SKILL.md 和 skills/proto-persona/SKILL.md