user-story-splitting by deanpeters/product-manager-skills
npx skills add https://github.com/deanpeters/product-manager-skills --skill user-story-splitting使用系统化的拆分模式,将大型用户故事、史诗或功能分解为更小、可独立交付的故事。通过这种方式,使工作更易于管理、降低风险、实现更快的反馈周期,并在敏捷开发中保持流畅性。此技能适用于用户故事、史诗以及任何无法在单个冲刺周期内完成的过大工作。
这不是随意切割——而是战略性的分解,在降低复杂性的同时保留用户价值。
基于 Richard Lawrence 和 Peter Green 的《人性化工作用户故事拆分指南》,该框架提供了 8 种系统化的工作拆分模式:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
从需要拆分的 故事/史诗/功能 开始。确保其使用用户故事格式编写(参考 skills/user-story/SKILL.md 或 skills/epic-hypothesis/SKILL.md)。
### 原始故事:
[包含用例和验收标准的故事格式]
使用 template.md 获取完整的填写结构和输出格式。
按顺序遍历 8 种拆分模式。找到适用的模式后即可停止。
提问: 这个故事是否包含多个连续步骤?
示例:
提问: 这个故事是否针对不同场景有不同的规则?
示例:
提问: 这个故事是否处理不同类型的数据或输入?
示例:
提问: 这个故事是否有多个“当”或“那么”语句?
示例:
注意: 这是故事需要拆分的最常见指标。如果你看到多个“当/那么”对,就沿着这些边界进行拆分。
提问: 这个故事是否需要可以增量交付的重大技术工作?
示例:
提问: 这个故事是否依赖多个外部系统或 API?
示例:
提问: 这个故事是否需要复杂的部署、基础设施或运维工作?
示例:
提问: 如果以上都不适用,是否存在需要厘清的未知因素或假设?
示例:
注意: TADs 不是故事——它们是实验。在编写故事之前,用它们来降低风险和澄清问题。
对于每个拆分,使用 skills/user-story/SKILL.md 中的格式编写完整的用户故事:
### 使用 [模式名称] 拆分 1:
#### 用户故事 [ID]:
- **摘要:** [简短标题]
**用例:**
- **作为一个** [角色]
- **我希望** [行动]
- **以便** [结果]
**验收标准:**
- **场景:** [描述]
- **假设:** [前置条件]
- **当:** [行动]
- **那么:** [结果]
提出以下问题:
如果任何答案为“否”,请进行修改。
完整拆分示例请参见 examples/sample.md。
迷你示例摘录:
### 原始故事:
作为一个团队管理员,我希望能够管理团队成员,以便控制访问权限。
### 建议的拆分(验收标准复杂度):
1. 邀请新团队成员
2. 移除团队成员
3. 更新团队成员角色
症状: “故事 1:构建 API。故事 2:构建 UI。”
后果: 两个故事都无法独立交付用户价值。
解决方法: 垂直拆分——每个故事都应包含前端 + 后端工作,以交付完整的面向用户的能力。
症状: “故事 1:添加按钮。故事 2:将按钮连接到 API。故事 3:显示结果。”
后果: 造成不必要的开销和依赖关系。
解决方法: 仅在故事太大时才拆分。一个 2 天的故事不需要拆分。
症状: “故事 1:功能的前半部分。故事 2:功能的后半部分。”
后果: 随意的拆分,无法映射到用户价值或工作流。
解决方法: 使用 8 种拆分模式之一——每个拆分都应有明确的理由。
症状: “故事 2 必须等到故事 1 100% 完成、测试并部署后才能开始。”
后果: 无法并行化,拖慢交付速度。
解决方法: 以允许独立开发的方式进行拆分。如果依赖不可避免,则优先处理故事 1。
症状: 拆分后的故事有相同的“以便”陈述。
后果: 你拆分的是行动而不是结果——这很可能是任务分解,而不是故事拆分。
解决方法: 确保每个拆分都有不同的用户结果。如果没有,请重新考虑拆分模式。
skills/user-story/SKILL.md — 编写拆分故事的格式skills/epic-hypothesis/SKILL.md — 史诗在成为故事之前通常需要拆分skills/jobs-to-be-done/SKILL.md — 有助于沿着用户任务进行有意义的拆分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 适用于: 用户故事、史诗以及任何无法在单个冲刺周期内完成的过大工作
每周安装量
239
代码仓库
GitHub 星标数
1.5K
首次出现
2026 年 2 月 12 日
安全审计
安装于
codex212
opencode211
gemini-cli208
github-copilot208
amp204
kimi-cli204
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.
Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:
Start with the story/epic/feature that needs splitting. Ensure it's written using the user story format (reference skills/user-story/SKILL.md or skills/epic-hypothesis/SKILL.md).
### Original Story:
[Story formatted with use case and acceptance criteria]
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.
Ask: Does this story contain multiple sequential steps?
Example:
Ask: Does this story have different rules for different scenarios?
Example:
Ask: Does this story handle different types of data or inputs?
Example:
Ask: Does this story have multiple "When" or "Then" statements?
Example:
Note: This is the most common indicator that a story needs splitting. If you see multiple "When/Then" pairs, split along those boundaries.
Ask: Does this story require significant technical work that can be delivered incrementally?
Example:
Ask: Does this story depend on multiple external systems or APIs?
Example:
Ask: Does this story require complex deployment, infrastructure, or operational work?
Example:
Ask: If none of the above apply, are there unknowns or assumptions that need unpacking?
Example:
Note: TADs aren't stories—they're experiments. Use them to de-risk and clarify before writing stories.
For each split, write a complete user story using the format from skills/user-story/SKILL.md:
### 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]
Ask these questions:
If any answer is "no," revise.
See examples/sample.md for full splitting examples.
Mini example excerpt:
### Original Story:
As a team admin, I want to manage team members so that I can control access.
### Suggested Splits (Acceptance Criteria Complexity):
1. Invite new team members
2. Remove team members
3. Update team member roles
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.
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.
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.
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.
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.
skills/user-story/SKILL.md — Format for writing the split storiesskills/epic-hypothesis/SKILL.md — Epics often need splitting before becoming storiesskills/jobs-to-be-done/SKILL.md — Helps identify meaningful splits along user jobsprompts/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
Weekly Installs
239
Repository
GitHub Stars
1.5K
First Seen
Feb 12, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex212
opencode211
gemini-cli208
github-copilot208
amp204
kimi-cli204
飞书日程待办摘要工作流:AI自动生成每日/每周开工报告,提升个人生产力
3,100 周安装
专业咨询分析技能:AI生成麦肯锡级研究报告,支持市场分析、财务分析、行业研究
430 周安装
Gemini CLI 更新日志自动化流程指南 | 技术文档版本管理最佳实践
430 周安装
tsdown - 基于Rolldown的极速TypeScript/JavaScript库打包工具,支持ESM/CJS/IIFE/UMD
430 周安装
PDF OCR技能:双引擎文字提取,支持影印PDF和图片识别
430 周安装
MUI v7 使用指南:组件样式、主题定制与响应式设计模式详解
431 周安装
HubSpot CRM 集成指南:使用 Membrane CLI 自动化销售、营销与客户服务
431 周安装