Back to Details

epic-breakdown-advisor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

Guide product managers through breaking down epics into user stories using Richard Lawrence's complete Humanizing Work methodology—a systematic, flowchart-driven approach that applies 9 splitting patterns sequentially. Use this to identify which pattern applies, split while preserving user value, and evaluate splits based on what they reveal about low-value work you can eliminate. This ensures vertical slicing (end-to-end value) rather than horizontal slicing (technical layers).
This is not arbitrary slicing—it's a proven, methodical process that starts with validation, walks through patterns in order, and evaluates results strategically.
指导产品经理采用Richard Lawrence完整的Humanizing Work方法论将史诗（Epic）拆分为用户故事——这是一种系统化的、基于流程图的方法，会依次应用9种拆分模式。借助此方法，你可以确定适用的模式，在拆分时保留用户价值，并根据拆分结果识别可剔除的低价值工作。这能确保采用垂直切片（端到端价值）而非水平切片（技术分层）的方式进行拆分。
这并非随意拆分，而是经过验证的系统化流程：从验证环节开始，按顺序应用模式，并从战略层面评估结果。

Key Concepts

核心概念

Core Principles: Vertical Slices Preserve Value

核心原则：垂直切片保留价值

A user story is "a description of a change in system behavior from the perspective of a user." Splitting must maintain vertical slices—work that touches multiple architectural layers and delivers observable user value—not horizontal slices addressing single components (e.g., "front-end story" + "back-end story").
用户故事是“从用户视角描述系统行为变化的内容”。拆分必须保持垂直切片——即涉及多个架构层并能交付可感知用户价值的工作——而非针对单一组件的水平切片（例如“前端故事”+“后端故事”）。

The Three-Step Process

三步流程

  1. Pre-Split Validation: Check if story satisfies INVEST criteria (except "Small")
  2. Apply Splitting Patterns: Work through 9 patterns sequentially until one fits
  3. Evaluate Splits: Choose the split that reveals low-value work or produces equal-sized stories
  1. 拆分前验证：检查故事是否满足INVEST准则（除“小型”外）
  2. 应用拆分模式：按顺序尝试9种模式，直到找到适用的模式
  3. 评估拆分结果：选择能揭示低价值工作或产出等规模故事的拆分方式

The 9 Splitting Patterns (In Order)

9种拆分模式（按顺序）

  1. Workflow Steps — Thin end-to-end slices, not step-by-step
  2. Operations (CRUD) — Create, Read, Update, Delete as separate stories
  3. Business Rule Variations — Different rules = different stories
  4. Data Variations — Different data types/structures
  5. Data Entry Methods — Simple UI first, fancy UI later
  6. Major Effort — "Implement one + add remaining"
  7. Simple/Complex — Core simplest version first, variations later
  8. Defer Performance — "Make it work" before "make it fast"
  9. Break Out a Spike — Time-box investigation when uncertainty blocks splitting
  1. 工作流步骤 — 薄型端到端切片，而非按步骤拆分
  2. 操作（CRUD） — 将创建、读取、更新、删除拆分为独立故事
  3. 业务规则变体 — 不同规则对应不同故事
  4. 数据变体 — 不同数据类型/结构
  5. 数据录入方式 — 先做简单UI，再做复杂UI
  6. 主要工作量 — “实现一个+补充剩余”
  7. 简单/复杂 — 先做核心最简版本，再做变体
  8. 延迟性能优化 — “先让它能用”再“让它变快”
  9. 拆分出探索任务（Spike） — 当不确定性阻碍拆分时，开展时间盒式调研

Meta-Pattern (Applies Across All Patterns)

元模式（适用于所有模式）

  1. Identify the core complexity
  2. List all variations
  3. Reduce variations to one complete slice
  4. Make other variations separate stories
  1. 识别核心复杂度
  2. 列出所有变体
  3. 简化为一个完整切片
  4. 将其他变体设为独立故事

Why This Works

该方法的优势

  • Prevents arbitrary splitting: Methodical checklist prevents guessing
  • Preserves user value: Every story delivers observable value
  • Reveals waste: Good splits expose low-value work you can deprioritize
  • Repeatable: Apply to any epic consistently
  • 避免随意拆分：系统化检查清单杜绝猜测
  • 保留用户价值：每个故事都能交付可感知的价值
  • 揭示冗余工作：优质拆分能暴露可低优先级处理的低价值工作
  • 可重复使用：可一致应用于任何史诗（Epic）

Facilitation Source of Truth

引导工作的参考标准

Use 
workshop-facilitation
 as the default interaction protocol for this skill.
It defines:
  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include 
    Other (specify)
    when useful)
This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
将
workshop-facilitation
作为此技能的默认交互协议。
它定义了：
  • 会话提醒与进入模式（引导式、上下文导出式、最佳猜测式）
  • 采用平实语言的单轮提问
  • 进度标签（例如：上下文问题X/8、评分问题X/5）
  • 中断处理与暂停/恢复机制
  • 决策点的编号建议
  • 常规问题的快速选择编号响应选项（必要时包含“其他（请说明）”）
本文档定义了特定领域的评估内容。若存在冲突，以本文档的领域逻辑为准。

Application

应用步骤

Step 0: Provide Epic Context

步骤0：提供史诗（Epic）上下文

Agent asks:
Please share your epic:
  • Epic title/ID
  • Description or hypothesis
  • Acceptance criteria (especially multiple "When/Then" pairs)
  • Target persona
  • Rough estimate
You can paste from Jira, Linear, or describe briefly.
Agent会询问：
请分享你的史诗（Epic）相关信息：
  • 史诗标题/ID
  • 描述或假设
  • 验收标准（尤其是多个“When/Then”规则）
  • 目标用户角色
  • 大致估算工作量
你可以从Jira、Linear粘贴内容，或简要描述。

Step 1: Pre-Split Validation (INVEST Check)

步骤1：拆分前验证（INVEST检查）

Before splitting, verify your story satisfies INVEST criteria (except "Small"):
Agent asks questions sequentially:
1. Independent? "Can this story be prioritized and developed without hard technical dependencies on other stories?"
Options:
  • Yes — No blocking dependencies
  • No — Requires other work first (flag this)
2. Negotiable? "Does this story leave room for the team to discover implementation details collaboratively, rather than prescribing exact solutions?"
Options:
  • Yes — It's a conversation starter, not a spec
  • No — It's too prescriptive (may need reframing)
3. Valuable? "Does this story deliver observable value to a user? (If not, combine it with related work rather than splitting.)"
Options:
  • Yes — Users see/experience something different
  • No — It's a technical task (not a user story—don't split, reframe)
⚠️ Critical Check: If story fails "Valuable," STOP. Don't split. Instead, combine with other work to create a meaningful increment.
4. Estimable? "Can your team size this story relatively (even if roughly)?"
Options:
  • Yes — Team can estimate days/points
  • No — Too much uncertainty (may need spike first)
5. Testable? "Does this story have concrete acceptance criteria that QA can verify?"
Options:
  • Yes — Clear pass/fail conditions
  • No — Needs clearer acceptance criteria (refine before splitting)
If story passes all checks → Proceed to Step 2 (Splitting Patterns) If story fails any check → Fix the issue before splitting
拆分前，验证你的故事是否满足INVEST准则（除“小型”外）：
Agent会依次提问：
1. 独立性？ “这个故事是否无需依赖其他故事的技术实现，就能被优先处理和开发？”
选项：
  • 是 — 无阻塞依赖
  • 否 — 需要先完成其他工作（标记此问题）
2. 可协商性？ “这个故事是否为团队留出了协作探索实现细节的空间，而非规定了精确的解决方案？”
选项：
  • 是 — 它是对话的起点，而非规范
  • 否 — 它过于具体化（可能需要重新梳理）
3. 价值性？ “这个故事是否能为用户交付可感知的价值？（如果不能，应与相关工作合并而非拆分。）”
选项：
  • 是 — 用户能看到/体验到变化
  • 否 — 它是一项技术任务（不是用户故事——不要拆分，重新梳理）
⚠️ 关键检查： 如果故事不满足“价值性”，请停止拆分。应将其与其他工作合并，以创建有意义的增量交付内容。
4. 可估算性？ “你的团队是否能相对准确地估算这个故事的工作量（即使只是大致估算）？”
选项：
  • 是 — 团队可以估算天数/故事点
  • 否 — 不确定性太高（可能需要先开展探索任务）
5. 可测试性？ “这个故事是否有QA可以验证的具体验收标准？”
选项：
  • 是 — 有明确的通过/失败条件
  • 否 — 需要更清晰的验收标准（拆分前先完善）
如果故事通过所有检查 → 进入步骤2（应用拆分模式） 如果故事未通过任何一项检查 → 先解决问题再拆分

Step 2: Apply Splitting Patterns Sequentially

步骤2：依次应用拆分模式

Work through patterns in order. For each pattern, ask "Does this apply?"
按顺序尝试模式。对于每个模式，询问“是否适用？”

Pattern 1: Workflow Steps

模式1：工作流步骤

Key insight: Split into thin end-to-end slices, not step-by-step. Start with a simple case covering the full workflow, then add intermediate steps as separate stories.
Agent asks: "Does your epic involve a multi-step workflow where you could deliver a simple case first, then add intermediate steps later?"
Example:
  • Original: "Publish content (requires editorial review, legal approval, staging)"
  • ❌ Wrong split (step-by-step): Story 1 = Editorial review, Story 2 = Legal approval, Story 3 = Publish
  • ✅ Right split (thin end-to-end):
    • Story 1: Publish content (simple path: author uploads, content goes live immediately—no reviews)
    • Story 2: Add editorial review step (now content waits for editor approval before going live)
    • Story 3: Add legal approval step (content waits for legal + editorial before going live)
Each story delivers full workflow, just with increasing sophistication.
Options:
  1. Yes, multi-step workflow → "Describe the workflow steps"
  2. No, single step → Continue to Pattern 2
If YES: Agent generates thin end-to-end slice splits.
核心思路： 拆分为薄型端到端切片，而非按步骤拆分。先做覆盖完整工作流的简单场景，再将中间步骤设为独立故事。
Agent会询问： “你的史诗是否涉及多步骤工作流，你可以先交付简单场景，再后续添加中间步骤？”
示例：
  • 原始史诗： “发布内容（需要编辑审核、法务批准、预发布）”
  • ❌ 错误拆分（按步骤）： 故事1 = 编辑审核，故事2 = 法务批准，故事3 = 发布
  • ✅ 正确拆分（薄型端到端）：
    • 故事1：发布内容（简单路径：作者上传后内容立即上线——无需审核）
    • 故事2：添加编辑审核步骤（现在内容需等待编辑批准后再上线）
    • 故事3：添加法务批准步骤（内容需等待法务+编辑批准后再上线）
每个故事都覆盖完整工作流，只是复杂度逐步提升。
选项：
  1. 是，有多步骤工作流 → “描述工作流步骤”
  2. 否，单步骤 → 继续模式2
如果选是： Agent会生成薄型端到端切片的拆分方案。

Pattern 2: Operations (CRUD)

模式2：操作（CRUD）

Key insight: The word "manage" signals multiple operations. Split into Create, Read, Update, Delete.
Agent asks: "Does your epic use words like 'manage,' 'handle,' or 'maintain'? If so, it likely bundles multiple operations (CRUD)."
Example:
  • Original: "Manage user accounts"
  • Split:
    • Story 1: Create user account
    • Story 2: View user account details
    • Story 3: Edit user account info
    • Story 4: Delete user account
Options:
  1. Yes, contains multiple operations → "List the operations (Create/Read/Update/Delete/etc.)"
  2. No, single operation → Continue to Pattern 3
If YES: Agent generates one story per operation.
核心思路： “管理”这类词意味着包含多个操作。拆分为创建、读取、更新、删除。
Agent会询问： “你的史诗是否使用了‘管理’、‘处理’或‘维护’这类词？如果是，它可能包含多个操作（CRUD）。”
示例：
  • 原始史诗： “管理用户账户”
  • 拆分结果：
    • 故事1：创建用户账户
    • 故事2：查看用户账户详情
    • 故事3：编辑用户账户信息
    • 故事4：删除用户账户
选项：
  1. 是，包含多个操作 → “列出操作（创建/读取/更新/删除等）”
  2. 否，单一操作 → 继续模式3
如果选是： Agent会为每个操作生成一个故事。

Pattern 3: Business Rule Variations

模式3：业务规则变体

Key insight: When identical functionality operates under different rules, each rule becomes its own story.
Agent asks: "Does your epic have different business rules for different scenarios (user types, regions, tiers, conditions)?"
Example:
  • Original: "Flight search with flexible dates (date range, specific weekends, date offsets)"
  • Split:
    • Story 1: Search by date range (+/- N days)
    • Story 2: Search by specific weekends only
    • Story 3: Search by date offsets (N days before/after)
Options:
  1. Yes, different rules → "Describe the rule variations"
  2. No, same rules for all → Continue to Pattern 4
If YES: Agent generates one story per rule variation.
核心思路： 当相同功能在不同规则下运行时，每个规则对应一个独立故事。
Agent会询问： “你的史诗是否针对不同场景（用户类型、地区、层级、条件）有不同的业务规则？”
示例：
  • 原始史诗： “灵活日期航班搜索（日期范围、特定周末、日期偏移）”
  • 拆分结果：
    • 故事1：按日期范围搜索（±N天）
    • 故事2：仅按特定周末搜索
    • 故事3：按日期偏移搜索（前后N天）
选项：
  1. 是，有不同规则 → “描述规则变体”
  2. 否，所有场景规则相同 → 继续模式4
如果选是： Agent会为每个规则变体生成一个故事。

Pattern 4: Data Variations

模式4：数据变体

Key insight: Complexity from handling different data types or structures. Add variations just-in-time as needed.
Agent asks: "Does your epic handle different data types, formats, or structures (e.g., file types, geographic levels, user attributes)?"
Example:
  • Original: "Geographic search (counties, cities/towns/neighborhoods, custom provider areas)"
  • Split:
    • Story 1: Search by county
    • Story 2: Add city/town/neighborhood search
    • Story 3: Add custom provider area search
Options:
  1. Yes, different data types → "List the data variations"
  2. No, single data type → Continue to Pattern 5
If YES: Agent generates one story per data variation (deliver simplest first).
核心思路： 复杂度来自处理不同数据类型或结构。按需添加变体。
Agent会询问： “你的史诗是否需要处理不同的数据类型、格式或结构（例如文件类型、地理层级、用户属性）？”
示例：
  • 原始史诗： “地理搜索（县、市/镇/社区、自定义服务商区域）”
  • 拆分结果：
    • 故事1：按县搜索
    • 故事2：添加市/镇/社区搜索
    • 故事3：添加自定义服务商区域搜索
选项：
  1. 是，有不同数据类型 → “列出数据变体”
  2. 否，单一数据类型 → 继续模式5
如果选是： Agent会为每个数据变体生成一个故事（先交付最简单的）。

Pattern 5: Data Entry Methods

模式5：数据录入方式

Key insight: UI complexity independent of core functionality. Build simplest interface first, then add sophisticated UI as follow-ups.
Agent asks: "Does your epic include fancy UI elements (date pickers, autocomplete, drag-and-drop) that aren't essential to core functionality?"
Example:
  • Original: "Search with calendar date picker"
  • Split:
    • Story 1: Search by date (basic text input: "YYYY-MM-DD")
    • Story 2: Add visual calendar picker UI
Options:
  1. Yes, fancy UI elements → "Describe the UI enhancements"
  2. No, basic UI only → Continue to Pattern 6
If YES: Agent generates Story 1 = basic input, Story 2+ = UI enhancements.
核心思路： UI复杂度独立于核心功能。先做最简界面，再后续添加复杂UI。
Agent会询问： “你的史诗是否包含非核心功能所需的复杂UI元素（日期选择器、自动补全、拖放）？”
示例：
  • 原始史诗： “带日历日期选择器的搜索”
  • 拆分结果：
    • 故事1：按日期搜索（基础文本输入：“YYYY-MM-DD”）
    • 故事2：添加可视化日历选择器UI
选项：
  1. 是，有复杂UI元素 → “描述UI增强功能”
  2. 否，仅基础UI → 继续模式6
如果选是： Agent会生成故事1 = 基础输入，故事2+ = UI增强功能。

Pattern 6: Major Effort

模式6：主要工作量

Key insight: When initial implementation carries most complexity, with additions being trivial. Frame as "implement one + add remaining."
Agent asks: "Does your epic involve building infrastructure where the first implementation is hard, but adding more is easy?"
Example:
  • Original: "Accept credit card payments (Visa, Mastercard, Amex, Discover)"
  • Split:
    • Story 1: Accept Visa payments (build full payment infrastructure)
    • Story 2: Add Mastercard, Amex, Discover support (trivial additions)
⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.
Options:
  1. Yes, major effort pattern → "What's the first implementation + what are the additions?"
  2. No, no infrastructure work → Continue to Pattern 7
If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.
核心思路： 当初始实现包含大部分复杂度，后续补充工作较简单时，采用“实现一个+补充剩余”的框架。
Agent会询问： “你的史诗是否涉及构建基础设施，其中首次实现难度大，但后续扩展容易？”
示例：
  • 原始史诗： “接受信用卡支付（Visa、Mastercard、Amex、Discover）”
  • 拆分结果：
    • 故事1：接受Visa支付（构建完整支付基础设施）
    • 故事2：添加Mastercard、Amex、Discover支持（简单补充）
⚠️ 注意： 第一个故事完成繁重工作（支付网关、安全、合规），后续故事只是简单补充。
选项：
  1. 是，符合主要工作量模式 → “首次实现内容是什么？剩余补充内容是什么？”
  2. 否，无基础设施工作 → 继续模式7
如果选是： Agent会生成故事1 = 构建基础设施，故事2 = 补充剩余变体。

Pattern 7: Simple/Complex

模式7：简单/复杂

Key insight: Identify story's core by asking "What's the simplest version?" Extract variations into separate stories.
Agent asks: "What's the simplest version of this epic that still delivers value? Can you strip away complexity and add it back later?"
Example:
  • Original: "Flight search (with max stops, nearby airports, flexible dates)"
  • Split:
    • Story 1: Basic flight search (origin, destination, date)
    • Story 2: Add max stops filter
    • Story 3: Add nearby airports option
    • Story 4: Add flexible dates option
Options:
  1. Yes, can identify simplest core → "Describe the simplest version + what variations to defer"
  2. No, it's already simple → Continue to Pattern 8
If YES: Agent generates Story 1 = simplest core, Story 2+ = variations.
核心思路： 通过询问“最简版本是什么？”识别故事核心，将变体拆分为独立故事。
Agent会询问： “这个史诗的最简版本是什么？它仍能交付价值吗？你能否剥离复杂度，后续再添加？”
示例：
  • 原始史诗： “航班搜索（含最大经停数、附近机场、灵活日期）”
  • 拆分结果：
    • 故事1：基础航班搜索（出发地、目的地、日期）
    • 故事2：添加最大经停数筛选
    • 故事3：添加附近机场选项
    • 故事4：添加灵活日期选项
选项：
  1. 是，能识别最简核心 → “描述最简版本+需延迟的变体”
  2. 否，已经是最简版本 → 继续模式8
如果选是： Agent会生成故事1 = 最简核心，故事2+ = 变体。

Pattern 8: Defer Performance

模式8：延迟性能优化

Key insight: Split "make it work" from "make it fast." Non-functional requirements (performance, security, scalability) can follow functional delivery.
Agent asks: "Can you deliver functional value first, then optimize performance/security/scalability later?"
Example:
  • Original: "Real-time search with <100ms response time"
  • Split:
    • Story 1: Search works (functional, no performance guarantee)
    • Story 2: Optimize search to <100ms (add caching, indexing)
Options:
  1. Yes, can defer optimization → "What's the functional version + what's the optimization?"
  2. No, performance is essential → Continue to Pattern 9
If YES: Agent generates Story 1 = functional, Story 2 = optimize.
核心思路： 将“先让它能用”和“让它变快”拆分。非功能需求（性能、安全、可扩展性）可在功能交付后再处理。
Agent会询问： “你能否先交付功能价值，再后续优化性能/安全/可扩展性？”
示例：
  • 原始史诗： “响应时间<100ms的实时搜索”
  • 拆分结果：
    • 故事1：搜索功能可用（功能完整，无性能保证）
    • 故事2：优化搜索至响应时间<100ms（添加缓存、索引）
选项：
  1. 是，可延迟优化 → “功能版本是什么？优化内容是什么？”
  2. 否，性能是核心要求 → 继续模式9
如果选是： Agent会生成故事1 = 功能完整版本，故事2 = 优化版本。

Pattern 9: Break Out a Spike

模式9：拆分出探索任务（Spike）

Key insight: Last resort when uncertainty prevents splitting. Time-box investigation to answer specific questions, then split implementation story with better understanding.
Agent says: "None of patterns 1-8 apply, which suggests high uncertainty. Before splitting, run a spike to reduce uncertainty."
A spike is a time-boxed investigation (not a story), answering questions like:
  • Is this technically feasible?
  • Which approach performs best?
  • What does the API actually return?
Agent asks: "What's the biggest unknown preventing you from splitting this epic?"
Options:
  1. Technical feasibility — "Can we build this with our stack?"
  2. Approach uncertainty — "Multiple ways to solve it, unclear which is best"
  3. External dependency — "Don't know what third-party API provides"
Agent recommends: → "Run a 1-2 day spike to answer [question]. After the spike, come back and we'll split the epic with better understanding."
⚠️ Spikes produce learning, not shippable code. After the spike, restart at Pattern 1.
核心思路： 当1-8模式都不适用时的最后手段，意味着高度不确定性。开展时间盒式调研以明确特定问题，再基于更清晰的认知拆分实现故事。
Agent会说明： “1-8模式都不适用，这意味着高度不确定性。拆分前，先开展**探索任务（Spike）**以降低不确定性。”
探索任务（Spike）是时间盒式调研（非故事），用于回答以下问题：
  • 技术上是否可行？
  • 哪种方案性能最佳？
  • API实际返回什么内容？
Agent会询问： “阻碍你拆分这个史诗的最大未知因素是什么？”
选项：
  1. 技术可行性 — “我们的技术栈能否实现这个功能？”
  2. 方案不确定性 — “有多种解决方案，不清楚哪种最佳”
  3. 外部依赖 — “不知道第三方API能提供什么”
Agent会建议： → “开展1-2天的探索任务以回答[问题]。完成后，再回来拆分这个史诗，届时你会有更清晰的认知。”
⚠️ 探索任务（Spike）产出的是认知，而非可交付代码。完成后，从模式1重新开始。

Step 3: Evaluate Split Quality

步骤3：评估拆分质量

After splitting, evaluate using these criteria:
Agent asks:
1. Does this split reveal low-value work you can deprioritize or eliminate?
  • Good splits expose the 80/20 principle: most value concentrates in a small portion of functionality
  • Example: After splitting "Flight search" into 4 stories, you realize "flexible dates" is rarely used → deprioritize or kill it
2. Does this split produce more equally-sized stories?
  • Equal-sized stories give Product Owners greater prioritization flexibility
  • Example: Instead of one 10-day epic, five 2-day stories allow reordering mid-sprint
If split doesn't satisfy either criterion, try a different pattern.
拆分完成后，按以下标准评估：
Agent会询问：
1. 这个拆分是否揭示了你可以低优先级处理或剔除的低价值工作？
  • 优质拆分符合80/20原则：大部分价值集中在小部分功能中
  • 示例：将“航班搜索”拆分为4个故事后，你发现“灵活日期”很少被使用 → 低优先级处理或剔除
2. 这个拆分是否产出了更均等规模的故事？
  • 等规模故事让产品负责人有更大的优先级调整灵活性
  • 示例：将一个10天的史诗拆分为5个2天的故事，允许在迭代中期重新排序
如果拆分不满足任一标准，尝试其他模式。

Meta-Pattern Application

元模式应用

Across all patterns, follow this sequence:
  1. Identify core complexity — What makes this epic hard?
  2. List variations — What are all the different ways/cases/rules?
  3. Reduce to one complete slice — Pick the simplest variation that still delivers end-to-end value
  4. Make other variations separate stories
所有模式都遵循以下流程：
  1. 识别核心复杂度 — 这个史诗的难点是什么？
  2. 列出所有变体 — 有哪些不同的方式/场景/规则？
  3. 简化为一个完整切片 — 选择仍能交付端到端价值的最简变体
  4. 将其他变体设为独立故事

Cynefin Domain Considerations

Cynefin复杂度域考量

Strategy shifts based on complexity domain:
Agent asks: "How much uncertainty surrounds this epic?"
Options:
  1. Low uncertainty (Obvious/Complicated domain) — "We know what to build; it's just engineering work" → Find all stories, prioritize by value/risk
  2. High uncertainty (Complex domain) — "We're not sure what customers want or what will work" → Identify 1-2 learning stories; avoid exhaustive enumeration (work itself teaches what matters)
  3. Chaos — "Everything is on fire; priorities shift daily" → Defer splitting until stability emerges; focus on stabilization first
策略会根据复杂度域调整：
Agent会询问： “这个史诗的不确定性有多高？”
选项：
  1. 低不确定性（明显/复杂域） — “我们知道要做什么，只是工程实现工作” → 找出所有故事，按价值/风险优先级排序
  2. 高不确定性（复杂域） — “我们不确定用户想要什么，也不确定什么方案可行” → 识别1-2个学习型故事；避免详尽枚举（工作本身会告诉你什么重要）
  3. 混沌域 — “一切都很混乱，优先级每天都在变” → 延迟拆分直到稳定；先专注于恢复稳定

Output: Generate Story Breakdown

输出：生成故事拆分方案

markdown
undefined
markdown
undefined

Epic Breakdown Plan

史诗拆分计划

Epic: [Original epic] Pre-Split Validation: ✅ Passes INVEST (except Small) Splitting Pattern Applied: [Pattern name] Rationale: [Why this pattern fits]
史诗： [原始史诗] 拆分前验证： ✅ 通过INVEST（除小型外） 应用的拆分模式： [模式名称] 理由： [该模式适用的原因]

Story Breakdown

故事拆分

Story 1: [Title] (Simplest Complete Slice)

故事1：[标题]（最简完整切片）

Summary: [User-value-focused title]
Use Case:
  • As a [persona]
  • I want to [action]
  • so that [outcome]
Acceptance Criteria:
  • Given: [Preconditions]
  • When: [Action]
  • Then: [Outcome]
Why This First: [Delivers core value; simpler variations follow] Estimated Effort: [Days/points]
摘要： [以用户价值为核心的标题]
用例：
  • 作为 [用户角色]
  • 我想要 [操作]
  • 以便 [结果]
验收标准：
  • 给定： [前置条件]
  • 当： [操作]
  • 则： [结果]
优先做此故事的原因： [交付核心价值；后续是更复杂的变体] 估算工作量： [天数/故事点]

Story 2: [Title] (First Variation)

故事2：[标题]（第一个变体）

[Repeat...]
[重复上述格式...]

Story 3: [Title] (Second Variation)

故事3：[标题]（第二个变体）

[Repeat...]
[重复上述格式...]

Split Evaluation

拆分评估

✅ Does this split reveal low-value work?
  • [Analysis: Which stories could be deprioritized/eliminated?]
✅ Does this split produce equal-sized stories?
  • [Analysis: Are stories roughly equal in effort?]
✅ 该拆分是否揭示了低价值工作？
  • [分析：哪些故事可以低优先级处理或剔除？]
✅ 该拆分是否产出了等规模故事？
  • [分析：故事的工作量是否大致均等？]

INVEST Validation (Each Story)

每个故事的INVEST验证

✅ Independent: Stories can be developed in any order ✅ Negotiable: Implementation details can be discovered collaboratively ✅ Valuable: Each story delivers observable user value ✅ Estimable: Team can size each story ✅ Small: Each story fits in 1-5 days ✅ Testable: Clear acceptance criteria for each
✅ 独立性： 故事可以按任意顺序开发 ✅ 可协商性： 实现细节可协作探索 ✅ 价值性： 每个故事都能交付可感知的用户价值 ✅ 可估算性： 团队可以估算每个故事的工作量 ✅ 小型： 每个故事的工作量在1-5天内 ✅ 可测试性： 每个故事都有清晰的验收标准

Next Steps

下一步行动

  1. Review with team: Do PM, design, engineering agree?
  2. Check for further splitting: Are any stories still >5 days? If yes, restart at Pattern 1 for that story.
  3. Prioritize: Which story delivers most value first?
  4. Consider eliminating: Did split reveal low-value stories? Kill or defer them.
If stories are still too large, re-apply patterns starting at Pattern 1.

---
  1. 与团队评审： 产品经理、设计、开发是否达成一致？
  2. 检查是否需要进一步拆分： 是否有故事的工作量仍超过5天？如果是，针对该故事从模式1重新开始拆分。
  3. 优先级排序： 哪个故事能最先交付最大价值？
  4. 考虑剔除： 拆分是否揭示了低价值故事？剔除或延迟处理它们。
如果故事仍过大，从模式1开始重新应用拆分模式。

---

Examples

示例

Example 1: Pattern 1 Applied (Workflow Steps - Thin End-to-End)

示例1：应用模式1（工作流步骤 - 薄型端到端）

Epic: "Publish blog post (requires editorial review, legal approval, staging)"
Pre-Split Validation: ✅ Passes INVEST
Pattern 1: "Does this have workflow steps?" → YES ✅
❌ Wrong Split (Step-by-Step):
  1. Editorial review story
  2. Legal approval story
  3. Publish story → Problem: Story 1 doesn't deliver value (users see nothing)
✅ Right Split (Thin End-to-End):
  1. Publish post (simple path) — Author uploads, post goes live immediately (no reviews)
  2. Add editorial review — Post now waits for editor approval before going live
  3. Add legal approval — Post waits for legal + editorial before going live
Why this works: Each story delivers full workflow, just with increasing sophistication.
史诗： “发布博客文章（需要编辑审核、法务批准、预发布）”
拆分前验证： ✅ 通过INVEST
模式1： “是否有工作流步骤？” → 是 ✅
❌ 错误拆分（按步骤）：
  1. 编辑审核故事
  2. 法务批准故事
  3. 发布故事 → 问题：故事1无法交付端到端价值（用户看不到任何变化）
✅ 正确拆分（薄型端到端）：
  1. 发布文章（简单路径） — 作者上传后文章立即上线（无需审核）
  2. 添加编辑审核 — 文章现在需等待编辑批准后再上线
  3. 添加法务批准 — 文章需等待法务+编辑批准后再上线
为何有效： 每个故事都覆盖完整工作流，只是复杂度逐步提升。

Example 2: Pattern 2 Applied (CRUD Operations)

示例2：应用模式2（CRUD操作）

Epic: "Manage user profiles"
Pattern 2: "Does this say 'manage'?" → YES ✅ (signals CRUD)
Split:
  1. Create user profile
  2. View user profile details
  3. Edit user profile info
  4. Delete user profile
Split Evaluation:
  • ✅ Reveals low-value work: After analysis, "Delete profile" is rarely used → deprioritize
  • ✅ Equal-sized stories: Each 1-2 days
史诗： “管理用户资料”
模式2： “是否包含‘管理’一词？” → 是 ✅（意味着CRUD操作）
拆分结果：
  1. 创建用户资料
  2. 查看用户资料详情
  3. 编辑用户资料信息
  4. 删除用户资料
拆分评估：
  • ✅ 揭示低价值工作： 分析后发现“删除资料”很少被使用 → 低优先级处理
  • ✅ 等规模故事： 每个故事的工作量为1-2天

Example 3: Pattern 7 Applied (Simple/Complex)

示例3：应用模式7（简单/复杂）

Epic: "Flight search with max stops, nearby airports, flexible dates"
Pattern 7: "What's the simplest version?" → Basic search ✅
Split:
  1. Basic flight search (origin, destination, date) — Core value
  2. Add max stops filter — Enhancement
  3. Add nearby airports option — Enhancement
  4. Add flexible dates option — Enhancement
Split Evaluation:
  • ✅ Reveals low-value work: User research shows "flexible dates" rarely used → kill or defer
  • ✅ Equal-sized stories: Story 1 = 3 days, others = 1 day each
史诗： “含最大经停数、附近机场、灵活日期的航班搜索”
模式7： “最简版本是什么？” → 基础搜索 ✅
拆分结果：
  1. 基础航班搜索（出发地、目的地、日期） — 核心价值
  2. 添加最大经停数筛选 — 增强功能
  3. 添加附近机场选项 — 增强功能
  4. 添加灵活日期选项 — 增强功能
拆分评估：
  • ✅ 揭示低价值工作： 用户研究显示“灵活日期”很少被使用 → 剔除或延迟处理
  • ✅ 等规模故事： 故事1 = 3天，其他故事 = 1天

Example 4: Iterative Splitting (Multiple Patterns)

示例4：迭代拆分（多模式组合）

Epic: "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"
First Pass - Pattern 1 (Workflow): YES ✅
  • Story 1: Add items to cart
  • Story 2: Apply discount
  • Story 3: Complete payment
Check Story 2 ("Apply discount"): Still 4 days → Too large, re-split
Second Pass on Story 2 - Pattern 3 (Business Rules): YES ✅
  • Story 2a: Apply member discount (10%)
  • Story 2b: Apply VIP discount (20%)
  • Story 2c: Apply first-time discount (5%)
Check Story 3 ("Complete payment"): Still 5 days → Too large, re-split
Third Pass on Story 3 - Pattern 6 (Major Effort): YES ✅
  • Story 3a: Accept Visa payments (build payment infrastructure)
  • Story 3b: Add Mastercard, Amex support
Final Breakdown: 6 stories, all 1-2 days each
史诗： “含折扣（会员、VIP、首次下单）和支付（Visa、Mastercard、Amex）的结账流程”
第一轮 - 模式1（工作流）： 是 ✅
  • 故事1：添加商品到购物车
  • 故事2：应用折扣
  • 故事3：完成支付
检查故事2（“应用折扣”）： 仍需4天 → 过大，重新拆分
第二轮针对故事2 - 模式3（业务规则）： 是 ✅
  • 故事2a：应用会员折扣（10%）
  • 故事2b：应用VIP折扣（20%）
  • 故事2c：应用首次下单折扣（5%）
检查故事3（“完成支付”）： 仍需5天 → 过大，重新拆分
第三轮针对故事3 - 模式6（主要工作量）： 是 ✅
  • 故事3a：接受Visa支付（构建支付基础设施）
  • 故事3b：添加Mastercard、Amex支持
最终拆分结果： 6个故事，每个故事的工作量为1-2天

Common Pitfalls

常见陷阱

Pitfall 1: Skipping Pre-Split Validation

陷阱1：跳过拆分前验证

Symptom: Jump straight to splitting without checking INVEST
Consequence: Split a story that shouldn't be split (e.g., not Valuable = technical task)
Fix: Always run Step 1 (INVEST check) before Step 2 (splitting patterns)
症状： 未检查INVEST就直接拆分
后果： 拆分了不应拆分的故事（例如不满足价值性的技术任务）
解决方法： 始终先执行步骤1（INVEST检查），再执行步骤2（应用拆分模式）

Pitfall 2: Step-by-Step Workflow Splitting (Pattern 1 Done Wrong)

陷阱2：按步骤拆分工作流（模式1使用错误）

Symptom: Story 1 = "Editorial review," Story 2 = "Legal approval"
Consequence: Stories don't deliver end-to-end value
Fix: Each story should cover full workflow (thin end-to-end slice), just with increasing sophistication
症状： 故事1 = “编辑审核”，故事2 = “法务批准”
后果： 故事无法交付端到端价值
解决方法： 每个故事都应覆盖完整工作流（薄型端到端切片），只是复杂度逐步提升

Pitfall 3: Horizontal Slicing (Technical Layers)

陷阱3：水平切片（技术分层）

Symptom: "Story 1: Build API. Story 2: Build UI."
Consequence: Neither story delivers user value
Fix: Vertical slicing—each story includes front-end + back-end to deliver observable user behavior
症状： “故事1：构建API。故事2：构建UI。”
后果： 两个故事都无法交付用户价值
解决方法： 垂直切片——每个故事都包含前端+后端，以交付可感知的用户行为变化

Pitfall 4: Forcing a Pattern That Doesn't Fit

陷阱4：强行套用不适用的模式

Symptom: "We'll split by workflow even though there's no sequence"
Consequence: Arbitrary, meaningless split
Fix: If pattern doesn't apply, say NO and continue to next pattern
症状： “即使没有序列，我们也要按工作流拆分”
后果： 随意、无意义的拆分
解决方法： 如果模式不适用，选择“否”并继续下一个模式

Pitfall 5: Not Re-Splitting Large Stories

陷阱5：未重新拆分大型故事

Symptom: Split epic into 3 stories, but each is still 5+ days
Consequence: Stories too large for sprint
Fix: Restart at Pattern 1 for each large story until all are 1-5 days
症状： 将史诗拆分为3个故事，但每个故事仍需5+天
后果： 故事过大，无法放入迭代
解决方法： 针对每个大型故事从模式1重新开始拆分，直到所有故事的工作量在1-5天内

Pitfall 6: Ignoring Split Evaluation (Step 3)

陷阱6：忽略拆分评估（步骤3）

Symptom: Split but don't evaluate if it reveals low-value work
Consequence: Miss opportunity to eliminate waste
Fix: After splitting, ask: "Does this reveal work we can kill or defer?"
症状： 拆分后未评估是否揭示了低价值工作
后果： 错失剔除冗余工作的机会
解决方法： 拆分后询问：“这个拆分是否揭示了我们可以剔除或延迟处理的工作？”

Practice & Skill Development

实践与技能提升

Humanizing Work recommendation: Teams reach fluency in 2.5-3 hours across multiple practice sessions.
Practice approach:
  1. Analyze recently completed features (hindsight makes patterns obvious)
  2. Walk completed work through the flowchart — Which pattern would have applied?
  3. Find multiple split approaches for each feature
  4. Build shared vocabulary of domain-specific pattern examples
Don't skip practice work. Skill develops through analyzing past deliverables, not just refining future work.
Humanizing Work建议： 团队通过多次实践会话，可在2.5-3小时内熟练掌握该方法。
实践方法：
  1. 分析近期完成的功能（事后复盘能让模式更清晰）
  2. 按流程图梳理已完成的工作 — 当时适用哪种模式？
  3. 为每个功能寻找多种拆分方式
  4. 构建领域特定模式示例的共享词汇表
不要跳过实践。 技能提升来自分析已交付的工作，而非仅优化未来工作。

References

参考资料

Related Skills

相关技能

  • user-story-splitting.md
    — The 9 patterns in detail
  • user-story.md
    — Format for writing stories
  • epic-hypothesis.md
    — Original epic format
  • user-story-splitting.md
    — 9种模式的详细说明
  • user-story.md
    — 故事撰写格式
  • epic-hypothesis.md
    — 原始史诗格式

External Frameworks

外部框架

  • Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — Complete methodology
  • Bill Wake, INVEST in Good Stories (2003) — Quality criteria
  • Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — 完整方法论
  • Bill Wake, INVEST in Good Stories (2003) — 质量准则

Sources

来源

Skill type: Interactive Suggested filename: 
epic-breakdown-advisor.md
Suggested placement: 
/skills/interactive/
Dependencies: Uses 
user-story-splitting.md
, 
user-story.md
, 
epic-hypothesis.md
技能类型： 交互式 建议文件名： 
epic-breakdown-advisor.md
建议存放路径： 
/skills/interactive/
依赖： 使用
user-story-splitting.md
, 
user-story.md
, 
epic-hypothesis.md