user-story-splitting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目的

Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.

This is not arbitrary slicing—it's strategic decomposition that preserves user value while reducing complexity.

使用系统化的拆分模式，将大型用户故事、Epic或功能拆分为更小、可独立交付的故事。借此让工作更易管理、降低风险、实现更快速的反馈周期，并在敏捷开发中保持工作流转。该技能适用于用户故事、Epic，以及任何无法在单个Sprint内完成的工作。

这不是随意的切割——而是在降低复杂度的同时保留用户价值的战略性分解。

Key Concepts

核心概念

The Story Splitting Framework

用户故事拆分框架

Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:

Workflow steps: Split along sequential steps in a user's journey
Business rule variations: Split by different rule scenarios (permissions, calculations, etc.)
Data variations: Split by different data types or inputs
Acceptance criteria complexity: Split when multiple "When" or "Then" statements exist
Major effort: Split by technical milestones or implementation phases
External dependencies: Split along dependency boundaries (APIs, third parties, etc.)
DevOps steps: Split by deployment or infrastructure requirements
Tiny Acts of Discovery (TADs): When none of the above apply, use small experiments to unpack unknowns

基于Richard Lawrence和Peter Green所著的《Humanizing Work Guide to Splitting User Stories》，该框架提供了8种系统化的工作拆分模式：

工作流步骤：沿用户旅程中的连续步骤进行拆分
业务规则变体：按不同的规则场景（权限、计算等）拆分
数据变体：按不同的数据类型或输入拆分
验收标准复杂度：当存在多个“When”或“Then”语句时进行拆分
主要工作量：按技术里程碑或实施阶段拆分
外部依赖：沿依赖边界（API、第三方服务等）拆分
DevOps步骤：按部署或基础设施要求拆分
微小探索行动（TADs）：当以上模式均不适用时，通过小型实验来拆解未知内容

Why Split Stories?

为什么要拆分故事？

Faster feedback: Smaller stories ship sooner, allowing earlier validation
Reduced risk: Less to build = less that can go wrong
Better estimation: Small stories are easier to estimate accurately
Maintain flow: Keeps work moving through the sprint without bottlenecks
Testability: Smaller scope = easier to write and run tests

更快的反馈：更小的故事能更快交付，实现更早的验证
降低风险：需要构建的内容越少，出错的可能性越低
更准确的估算：小型故事更容易进行准确估算
保持工作流转：让工作在Sprint中顺畅推进，避免瓶颈
可测试性：范围越小，编写和运行测试越容易

Anti-Patterns (What This Is NOT)

反模式（注意避免）

Not horizontal slicing: Don't split into "front-end story" and "back-end story" (each story should deliver user value)
Not task decomposition: Stories aren't tasks ("Set up database," "Write API")
Not arbitrary chopping: Don't split "Add user management" into "Add user" and "Management" (meaningless)

非横向拆分：不要拆分为“前端故事”和“后端故事”（每个故事都应交付用户价值）
非任务分解：故事不是任务（如“搭建数据库”、“编写API”）
非随意切割：不要将“添加用户管理”拆分为“添加用户”和“管理”（这种拆分毫无意义）

When to Use This

适用场景

Story is too large for a single sprint
Multiple "When" or "Then" statements in acceptance criteria
Epic needs to be broken down into deliverable increments
Team can't reach consensus on story size or scope
Story has multiple personas or workflows bundled together

故事规模过大，无法在单个Sprint内完成
验收标准中存在多个“When”或“Then”语句
Epic需要拆解为可交付的增量
团队无法就故事的规模或范围达成共识
故事中捆绑了多个角色或工作流

When NOT to Use This

不适用场景

Story is already small and well-scoped (don't over-split)
Splitting would create dependencies that slow delivery
The story is a technical task (use engineering task breakdown instead)

故事已经很小且范围清晰（不要过度拆分）
拆分后会产生依赖关系，拖慢交付速度
故事是技术任务（应使用工程任务分解方法）

Application

应用步骤

Step 1: Identify the Original Story

步骤1：确定原始故事

Start with the story/epic/feature that needs splitting. Ensure it's written using the user story format (reference

skills/user-story/SKILL.md

skills/epic-hypothesis/SKILL.md

markdown

undefined

从需要拆分的故事/Epic/功能开始。确保其采用用户故事格式编写（参考

skills/user-story/SKILL.md

或

skills/epic-hypothesis/SKILL.md

）。

markdown

undefined

Original Story:

[Story formatted with use case and acceptance criteria]

---

[Story formatted with use case and acceptance criteria]

---

Step 2: Apply the Splitting Logic

步骤2：应用拆分逻辑

Use

template.md

for the full fill-in structure and output format.

Work through the 8 splitting patterns in order. Stop when you find one that applies.

使用

template.md

获取完整的填充结构和输出格式。

按顺序尝试8种拆分模式，找到适用的模式后停止。

Pattern 1: Workflow Steps

模式1：工作流步骤

Ask: Does this story contain multiple sequential steps?

Example:

Original: "As a user, I want to sign up, verify my email, and complete onboarding"
Split:
1. "As a user, I want to sign up with email/password"
2. "As a user, I want to verify my email via a confirmation link"
3. "As a user, I want to complete onboarding by answering 3 profile questions"

问题：该故事是否包含多个连续步骤？

示例：

原始故事："As a user, I want to sign up, verify my email, and complete onboarding"
拆分后：
1. "As a user, I want to sign up with email/password"
2. "As a user, I want to verify my email via a confirmation link"
3. "As a user, I want to complete onboarding by answering 3 profile questions"

Pattern 2: Business Rule Variations

模式2：业务规则变体

Ask: Does this story have different rules for different scenarios?

Example:

Original: "As a user, I want to apply discounts (10% for members, 20% for VIPs, 5% for first-time buyers)"
Split:
1. "As a member, I want to apply a 10% discount at checkout"
2. "As a VIP, I want to apply a 20% discount at checkout"
3. "As a first-time buyer, I want to apply a 5% discount at checkout"

问题：该故事是否针对不同场景有不同规则？

示例：

原始故事："As a user, I want to apply discounts (10% for members, 20% for VIPs, 5% for first-time buyers)"
拆分后：
1. "As a member, I want to apply a 10% discount at checkout"
2. "As a VIP, I want to apply a 20% discount at checkout"
3. "As a first-time buyer, I want to apply a 5% discount at checkout"

Pattern 3: Data Variations

模式3：数据变体

Ask: Does this story handle different types of data or inputs?

Example:

Original: "As a user, I want to upload files (images, PDFs, videos)"
Split:
1. "As a user, I want to upload image files (JPG, PNG)"
2. "As a user, I want to upload PDF documents"
3. "As a user, I want to upload video files (MP4, MOV)"

问题：该故事是否处理不同类型的数据或输入？

示例：

原始故事："As a user, I want to upload files (images, PDFs, videos)"
拆分后：
1. "As a user, I want to upload image files (JPG, PNG)"
2. "As a user, I want to upload PDF documents"
3. "As a user, I want to upload video files (MP4, MOV)"

Pattern 4: Acceptance Criteria Complexity

模式4：验收标准复杂度

Ask: Does this story have multiple "When" or "Then" statements?

Example:

Original: "As a user, I want to manage my cart"
- When I add an item, Then it appears in my cart
- When I remove an item, Then it disappears from my cart
- When I update quantity, Then the cart total updates
Split:
1. "As a user, I want to add items to my cart so I can purchase them later"
2. "As a user, I want to remove items from my cart so I can change my mind"
3. "As a user, I want to update item quantities so I can buy the right amount"

Note: This is the most common indicator that a story needs splitting. If you see multiple "When/Then" pairs, split along those boundaries.

问题：该故事是否有多个“When”或“Then”语句？

示例：

原始故事："As a user, I want to manage my cart"
- When I add an item, Then it appears in my cart
- When I remove an item, Then it disappears from my cart
- When I update quantity, Then the cart total updates
拆分后：
1. "As a user, I want to add items to my cart so I can purchase them later"
2. "As a user, I want to remove items from my cart so I can change my mind"
3. "As a user, I want to update item quantities so I can buy the right amount"

注意：这是故事需要拆分的最常见指标。如果看到多个“When/Then”对，就沿着这些边界拆分。

Pattern 5: Major Effort

模式5：主要工作量

Ask: Does this story require significant technical work that can be delivered incrementally?

Example:

Original: "As a user, I want real-time collaboration on documents"
Split:
1. "As a user, I want to see who else is viewing the document (read-only presence)"
2. "As a user, I want to see live cursor positions of other editors"
3. "As a user, I want to see live edits from other users in real-time"

问题：该故事是否需要可增量交付的大量技术工作？

示例：

原始故事："As a user, I want real-time collaboration on documents"
拆分后：
1. "As a user, I want to see who else is viewing the document (read-only presence)"
2. "As a user, I want to see live cursor positions of other editors"
3. "As a user, I want to see live edits from other users in real-time"

Pattern 6: External Dependencies

模式6：外部依赖

Ask: Does this story depend on multiple external systems or APIs?

Example:

Original: "As a user, I want to log in with Google, Facebook, or Twitter"
Split:
1. "As a user, I want to log in with Google OAuth"
2. "As a user, I want to log in with Facebook OAuth"
3. "As a user, I want to log in with Twitter OAuth"

问题：该故事是否依赖多个外部系统或API？

示例：

原始故事："As a user, I want to log in with Google, Facebook, or Twitter"
拆分后：
1. "As a user, I want to log in with Google OAuth"
2. "As a user, I want to log in with Facebook OAuth"
3. "As a user, I want to log in with Twitter OAuth"

Pattern 7: DevOps Steps

模式7：DevOps步骤

Ask: Does this story require complex deployment, infrastructure, or operational work?

Example:

Original: "As a user, I want to upload large files to cloud storage"
Split:
1. "As a user, I want to upload small files (<10MB) to cloud storage"
2. "As a user, I want to upload large files (10MB-1GB) with progress tracking"
3. "As a user, I want to resume interrupted uploads"

问题：该故事是否需要复杂的部署、基础设施或运维工作？

示例：

原始故事："As a user, I want to upload large files to cloud storage"
拆分后：
1. "As a user, I want to upload small files (<10MB) to cloud storage"
2. "As a user, I want to upload large files (10MB-1GB) with progress tracking"
3. "As a user, I want to resume interrupted uploads"

Pattern 8: Tiny Acts of Discovery (TADs)

模式8：微小探索行动（TADs）

Ask: If none of the above apply, are there unknowns or assumptions that need unpacking?

Example:

Original: "As a user, I want AI-powered recommendations" (too vague, too many unknowns)
TADs:
1. Prototype 3 recommendation algorithms and test with 10 users
2. Define success criteria (click-through rate, user satisfaction)
3. Build the simplest recommendation engine (collaborative filtering)
4. Measure and iterate

Note: TADs aren't stories—they're experiments. Use them to de-risk and clarify before writing stories.

问题：如果以上模式均不适用，是否存在需要拆解的未知因素或假设？

示例：

原始故事："As a user, I want AI-powered recommendations"（过于模糊，存在太多未知）
TADs：
1. 原型开发3种推荐算法并对10名用户进行测试
2. 定义成功标准（点击率、用户满意度）
3. 构建最简单的推荐引擎（协同过滤）
4. 衡量结果并迭代优化

注意：TADs不是故事——它们是实验。用于在编写故事前降低风险并明确需求。

Step 3: Write the Split Stories

步骤3：编写拆分后的故事

For each split, write a complete user story using the format from

skills/user-story/SKILL.md

markdown

undefined

对于每个拆分出的内容，使用

skills/user-story/SKILL.md

中的格式编写完整的用户故事：

markdown

undefined

Split 1 using [Pattern Name]:

User Story [ID]:

Summary: [Brief title]

Use Case:

As a [persona]
I want to [action]
so that [outcome]

Acceptance Criteria:

Scenario: [Description]
Given: [Preconditions]
When: [Action]
Then: [Outcome]

---

Summary: [Brief title]

Use Case:

As a [persona]
I want to [action]
so that [outcome]

Acceptance Criteria:

Scenario: [Description]
Given: [Preconditions]
When: [Action]
Then: [Outcome]

---

Step 4: Validate the Splits

步骤4：验证拆分结果

Ask these questions:

Does each split deliver user value? (Not just "front-end done")
Can each split be developed independently? (No hard dependencies)
Can each split be tested independently? (Clear acceptance criteria)
Is each split small enough for a sprint? (1-5 days of work)
Do the splits, when combined, equal the original? (Nothing lost in translation)

If any answer is "no," revise.

提出以下问题：

每个拆分出的内容是否交付用户价值？（不只是“前端完成”）
每个拆分出的内容是否可独立开发？（无强依赖）
每个拆分出的内容是否可独立测试？（有明确的验收标准）
每个拆分出的内容是否足够小，可在一个Sprint内完成？（1-5天的工作量）
所有拆分内容组合后是否等同于原始故事？（没有遗漏任何内容）

如果有任何问题的答案为“否”，则需要修改拆分结果。

Examples

示例

See

examples/sample.md

for full splitting examples.

Mini example excerpt:

markdown

undefined

完整的拆分示例请查看

examples/sample.md

。

示例片段：

markdown

undefined

Original Story:

As a team admin, I want to manage team members so that I can control access.

Suggested Splits (Acceptance Criteria Complexity):

Invite new team members
Remove team members
Update team member roles

---

Invite new team members
Remove team members
Update team member roles

---

Common Pitfalls

常见陷阱

Pitfall 1: Horizontal Slicing (Technical Layers)

陷阱1：横向拆分（技术分层）

Symptom: "Story 1: Build the API. Story 2: Build the UI."

Consequence: Neither story delivers user value independently.

Fix: Split vertically—each story should include front-end + back-end work to deliver a complete user-facing capability.

症状：“故事1：构建API。故事2：构建UI。”

后果：两个故事都无法独立交付用户价值。

解决方法：纵向拆分——每个故事应包含前端+后端工作，以交付完整的用户可用功能。

Pitfall 2: Over-Splitting

陷阱2：过度拆分

Symptom: "Story 1: Add button. Story 2: Wire button to API. Story 3: Display result."

Consequence: Creates unnecessary overhead and dependencies.

Fix: Only split when the story is too large. A 2-day story doesn't need splitting.

症状：“故事1：添加按钮。故事2：将按钮连接到API。故事3：显示结果。”

后果：产生不必要的开销和依赖关系。

解决方法：仅当故事规模过大时才拆分。2天工作量的故事无需拆分。

Pitfall 3: Meaningless Splits

陷阱3：无意义拆分

Symptom: "Story 1: First half of feature. Story 2: Second half of feature."

Consequence: Arbitrary splits that don't map to user value or workflow.

Fix: Use one of the 8 splitting patterns—each split should have a clear rationale.

症状：“故事1：功能的前半部分。故事2：功能的后半部分。”

后果：随意的拆分与用户价值或工作流无关。

解决方法：使用8种拆分模式之一——每个拆分都应有明确的理由。

Pitfall 4: Creating Hard Dependencies

陷阱4：产生强依赖

Symptom: "Story 2 can't start until Story 1 is 100% done, tested, and deployed."

Consequence: No parallelization, slows delivery.

Fix: Split in a way that allows independent development. If dependencies are unavoidable, prioritize Story 1.

症状：“故事2必须在故事1100%完成、测试并部署后才能开始。”

后果：无法并行开发，拖慢交付速度。

解决方法：以允许独立开发的方式拆分。如果依赖不可避免，则优先处理故事1。

Pitfall 5: Ignoring the "So That"

陷阱5：忽略“So That”部分

Symptom: Split stories have the same "so that" statement.

Consequence: You've split the action but not the outcome—likely a task decomposition, not a story split.

Fix: Ensure each split has a distinct user outcome. If not, reconsider the split pattern.

症状：拆分后的故事具有相同的“So That”语句。

后果：仅拆分了动作但未拆分结果——这可能是任务分解，而非故事拆分。

解决方法：确保每个拆分出的内容都有独特的用户结果。如果没有，重新考虑拆分模式。

References

参考资料

Related Skills

External Frameworks

外部框架

Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — Origin of the 8 splitting patterns
Bill Wake, INVEST in Good Stories (2003) — Criteria for well-formed stories (Independent, Negotiable, Valuable, Estimable, Small, Testable)
Mike Cohn, User Stories Applied (2004) — Story decomposition techniques

Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — 8种拆分模式的来源
Bill Wake, INVEST in Good Stories (2003) — 优质故事的标准（Independent、Negotiable、Valuable、Estimable、Small、Testable）
Mike Cohn, User Stories Applied (2004) — 故事分解技术

Dean's Work

Dean的相关工作

User Story Splitting Prompt Template (based on Humanizing Work framework)

User Story Splitting Prompt Template（基于Humanizing Work框架）

Provenance

来源

Adapted from

prompts/user-story-splitting-prompt-template.md

in the

https://github.com/deanpeters/product-manager-prompts

repo.

Skill type: Component Suggested filename:

user-story-splitting.md

Suggested placement:

/skills/components/

Dependencies: References

skills/user-story/SKILL.md

skills/epic-hypothesis/SKILL.md

Applies to: User stories, epics, and any work that's too large to complete in a single sprint

改编自

https://github.com/deanpeters/product-manager-prompts

仓库中的

prompts/user-story-splitting-prompt-template.md

。

技能类型：组件 建议文件名：

user-story-splitting.md

建议存放位置：

/skills/components/

依赖：参考

skills/user-story/SKILL.md

、

skills/epic-hypothesis/SKILL.md

适用范围：用户故事、Epic，以及任何无法在单个Sprint内完成的工作

user-story-splitting

Original

Translation

Purpose

目的

Key Concepts

核心概念

The Story Splitting Framework

用户故事拆分框架

Why Split Stories?

为什么要拆分故事？

Anti-Patterns (What This Is NOT)

反模式（注意避免）

When to Use This

适用场景

When NOT to Use This

不适用场景

Application

应用步骤

Step 1: Identify the Original Story

步骤1：确定原始故事

Original Story:

Original Story:

Step 2: Apply the Splitting Logic

步骤2：应用拆分逻辑

Pattern 1: Workflow Steps

模式1：工作流步骤

Pattern 2: Business Rule Variations

模式2：业务规则变体

Pattern 3: Data Variations

模式3：数据变体

Pattern 4: Acceptance Criteria Complexity

模式4：验收标准复杂度

Pattern 5: Major Effort

模式5：主要工作量

Pattern 6: External Dependencies

模式6：外部依赖

Pattern 7: DevOps Steps

模式7：DevOps步骤

Pattern 8: Tiny Acts of Discovery (TADs)

模式8：微小探索行动（TADs）

Step 3: Write the Split Stories

步骤3：编写拆分后的故事

Split 1 using [Pattern Name]:

Split 1 using [Pattern Name]:

User Story [ID]:

User Story [ID]:

Step 4: Validate the Splits

步骤4：验证拆分结果

Examples

示例

Original Story:

Original Story:

Suggested Splits (Acceptance Criteria Complexity):

Suggested Splits (Acceptance Criteria Complexity):

Common Pitfalls

常见陷阱

Pitfall 1: Horizontal Slicing (Technical Layers)

陷阱1：横向拆分（技术分层）

Pitfall 2: Over-Splitting

陷阱2：过度拆分

Pitfall 3: Meaningless Splits

陷阱3：无意义拆分

Pitfall 4: Creating Hard Dependencies

陷阱4：产生强依赖

Pitfall 5: Ignoring the "So That"

陷阱5：忽略“So That”部分

References

参考资料

Related Skills

相关技能

External Frameworks

外部框架

Dean's Work

Dean的相关工作

Provenance

来源