需要把扁平 backlog…

当你需要为新系统、功能区域、用户旅程或重构项目，通过自适应提问引导团队创建二维用户故事地图并划分发布切片时使用。

适用场景

解决思路

1. 使用 workshop-facilitation 作为本技能的默认交互协议。
2. 按 workshop-facilitation 定义执行 session heads-up 和 entry mode（Guided、Context dump、Best guess）。
3. 按 workshop-facilitation 定义执行 one-question turns with plain-language prompts。
4. 按 workshop-facilitation 定义使用 progress labels，例如 Context Qx/8 和 Scoring Qx/5。
5. 按 workshop-facilitation 定义处理 interruption 以及 pause/resume behavior。
6. 按 workshop-facilitation 定义在 decision points 给出 numbered recommendations。
7. 按 workshop-facilitation 定义为 regular questions 提供 quick-select numbered response options，必要时包含 Other (specify)。
8. 本文件定义 domain-specific assessment content；如果 workshop-facilitation 与本文件冲突，遵循本文件领域逻辑。
9. 本 interactive skill 最多问 5 个 adaptive questions，每一步提供 3-4 个 enumerated options。
10. 使用 template.md 作为 facilitation agenda 和 outputs checklist。
11. 与 skills/workshop-facilitation/SKILL.md 配对，实现 one-step-at-a-time flow、decision points 的 numbered recommendations、regular questions 的 quick-select options；如果用户要求 single-shot output，跳过 multi-turn facilitation。
12. Step 0：在提问前收集上下文，建议先收集 Product/Feature Context：要映射的系统或功能；产品概念、PRD 草稿或现有 backlog；网站文案、定位材料或用户流程；现有用户故事（如果从扁平 backlog 迁移）。
13. Step 0：收集 User Context：目标 personas 或用户细分；用户研究、访谈或 journey maps；Jobs-to-be-done 或问题陈述。
14. Step 0：让用户直接粘贴上述内容，或简要描述系统。
15. Question 1：询问 scope，使用问题 What are you mapping? (What's the scope?)。
16. Question 1：提供 4 个 enumerated options：1 Entire product — Full end-to-end system from discovery to completion（适合新产品或 full rewrites）；2 Major feature area — 较大产品中的特定工作流，例如 onboarding、checkout、reporting（适合 feature launches）；3 User journey — 特定用户目标或 job-to-be-done，例如 hire a contractor、file taxes（适合 JTBD-driven mapping）；4 Redesign/refactor — 正在重建或简化的现有产品/功能（适合 legacy system modernization）。
17. Question 1：或让用户描述具体 scope。
18. Question 2：询问 primary users，使用问题 Who are the primary users for this map? (List personas or user segments.)。
19. Question 2：提供 4 个 enumerated options：1 Single persona — 一个主要用户类型，例如 small business owner（简化 mapping，适合 MVP）；2 Multiple personas, shared workflow — 不同用户类型、相同 core activities，例如 buyer 和 seller 都 browse listings（适合 marketplaces）；3 Multiple personas, different workflows — 不同用户类型且 distinct workflows，例如 admin vs. end user（需要 separate maps 或 swim lanes）；4 Roles within organization — 不同 job functions，例如 PM、designer、engineer（适合 internal tools）。
20. Question 2：使用 Step 0 上下文中的 personas（proto-personas、JTBD 等）进行适配。
21. Question 2：或让用户描述 users。
22. Question 3：基于 scope（Q1）和 users（Q2）生成 5-8 个 activities 作为 backbone，按 workflow 从左到右排列。
23. Question 3：示例（scope = E-commerce checkout）backbone：Browse Products → Add to Cart → Review Cart → Enter Shipping Info → Enter Payment Info → Confirm Order → Receive Confirmation。
24. Question 3：询问 Does this backbone capture the full workflow? Should we add, remove, or reorder activities?。
25. Question 3：根据用户 response 批准、修改或添加 custom activities。
26. Question 4：在每个 activity 下生成 3-5 个 user tasks，按 priority 垂直排列（top = must-have，bottom = nice-to-have）。
27. Question 4：示例（Activity 2: Add to Cart）：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）。
28. Question 4：对所有 backbone activities 重复生成，并展示 full map。
29. Question 4：询问 Does this capture the key tasks? Are priorities correct (top = MVP, bottom = later releases)?。
30. Question 4：根据用户 response 批准、修改或添加 custom tasks。
31. Question 5：通过在地图上画 horizontal lines 定义 release slices。
32. Question 5：生成 3 个 release slices：Release 1 (Walking Skeleton)：所有 activities 中 top-priority tasks，minimal end-to-end functionality；Release 2 (Next Increment)：second-priority tasks，增强 core workflow；Release 3 (Polish/Expansion)：third-priority tasks，包括 nice-to-haves、edge cases、optimizations。
33. Question 5：示例 Release 1：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。
34. Question 5：示例 Release 2：Product filtering/search、Adjust quantity in cart、Save for later、Multiple shipping options、Multiple payment methods、Order tracking link。
35. Question 5：示例 Release 3：Product recommendations、Guest checkout、Gift wrapping、Promo codes、Advanced payment options、Post-purchase surveys。
36. Question 5：询问 Do these release slices make sense? Should we adjust scope or priorities?。
37. Question 5：根据用户 response 批准或修改。
38. Output：生成 markdown 格式的 User Story Map：标题 # User Story Map: [Scope from Q1]；Users: [From Q2]；Date: [Today's date]。
39. Output：Backbone (Activities) 部分用箭头连接：[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5] → [Activity 6]。
40. Output：Full Story Map 部分：每个 [Activity N: Name] 下列出 [Task N.x] — Must-have (Release 1) / Should-have (Release 2) / Nice-to-have (Release 3)；对所有 activities 重复。
41. Output：Release Slices 部分：Release 1: Walking Skeleton (MVP)，Goal: Minimal end-to-end functionality，Stories 列出每个 activity 的 Task x.1；Why this is the walking skeleton：Delivers complete workflow with simplest version of each activity。
42. Output：Release 2: Enhanced Functionality，Goal: Improve core workflow with priority enhancements，Stories 列出 Task x.2。
43. Output：Release 3: Polish & Expansion，Goal: Nice-to-haves, edge cases, optimizations，Stories 列出 Task x.3。
44. Output：Next Steps：1 Refine stories：使用 skills/user-story/SKILL.md 写带 acceptance criteria 的 detailed stories；2 Estimate effort：对 stories 评分（story points、t-shirt sizes）；3 Validate with stakeholders：从左到右 walk through map，确认 priorities；4 Display map：打印/张贴作为 information radiator 供 ongoing reference。
45. Output：最后提示 Ready to write user stories? 可 refine map 或 break down specific stories。
46. 关键原则：水平轴将 activities 按 narrative/workflow order 从左到右排列。
47. 关键原则：垂直轴在 each activity 内按 priority 从上到下排列。
48. 关键原则：Backbone 由 essential activities 组成系统 structural core；这些 activities 不相互 prioritization，而是 narrative flow。
49. 关键原则：Walking Skeleton 是跨所有 activities 的最高优先级 tasks，形成 minimal viable product。
50. 关键原则：Ribs 是每个 activity 下垂直下降的 supporting tasks，通过 placement 表示 priority。
51. 关键原则：采用 Left-to-Right, Top-to-Bottom Build Strategy，跨所有主要 features 增量构建，而不是先完整完成一个 feature 再开始另一个。
52. 避免/修复 Pitfall 1：如果 story map 只是 vertical list、没有 horizontal narrative，强制 horizontal structure——activities 在顶部，tasks 垂直下降。
53. 避免/修复 Pitfall 2：如果 backbone = Frontend → Backend → Database，改为遵循 user workflow，不是 system layers。
54. 避免/修复 Pitfall 3：如果 Release 1 = Build Activity 1 fully、Release 2 = Build Activity 2 fully，改为 walking skeleton = thin slice across ALL activities，逐步增强。
55. 避免/修复 Pitfall 4：不要一开始映射每个 edge case 和 acceptance criterion；从 backbone + high-level tasks 开始，later refine。
56. 避免/修复 Pitfall 5：不要把 story map 藏在 Jira/Miro 中而不展示；打印/张贴 map，使其每天对团队 visible。
57. 好故事地图检查：backbone 遵循 user narrative（不是 technical layers）；walking skeleton 交付 end-to-end value；incremental releases 增加 sophistication 而不破坏 core flow。
58. 坏故事地图修复：backbone 不能是 UI Layer → API Layer → Database Layer → Deployment；应改为 user workflow，例如 Sign Up → Configure Settings → Invite Team → Start Project；每个 release 交付 full workflow，不是 single layer。
59. 注意 anti-patterns：story map 不是 Gantt chart，显示 priority 而不是 time estimates；不是 technical architecture，跟随 user workflow 而不是 system layers (UI → API → DB)；不是 project plan，是 discovery 和 communication tool，不是 schedule。

适用边界 · 注意事项

• 单功能项目：story map 属于 overkill。
• backlog 已经充分理解并排好优先级时。
• 技术重构工作：没有 user workflow 可映射。