用户故事拆分 (User Story Splitting) - 把过大的故事拆成可独立交付的小故事

技能概述

用户故事拆分技能基于 Humanizing Work 框架的 8 种拆分模式,帮助产品经理和敏捷团队把过大的用户故事或 Epic 拆解为可独立交付、独立测试的小故事,让估算、排序和发布更顺畅。

适用场景

1. 故事太大,估不了也做不完: 一个用户故事横跨整个迭代仍无法收尾,团队给不出可靠的估算,需要沿工作流步骤、数据类型等维度做纵向拆分,而不是凭感觉砍半。
2. 按前后端拆分不奏效: 团队习惯把故事拆成"前端故事 + 后端故事",结果两边都无法独立交付用户价值,需要换成真正以用户价值为切面的拆分模式。
3. 待办事项频繁延期: Backlog 里的条目反复顺延到下个迭代,交付节奏被大故事卡住,需要用系统化拆分缩小批量、降低风险、加快反馈循环。

核心功能

1. 8 种系统化拆分模式: 依次套用工作流步骤、业务规则变化、数据变化、验收标准复杂度、重大投入、外部依赖、DevOps 步骤和微小发现实验(TADs)8 种模式,逐一定位最适合当前故事的拆分切面,找到即停,避免无依据的任意切分。
2. 标准化的拆分输出: 每个拆分结果都按标准用户故事格式输出,包含"作为谁 / 我想要 / 以便于"的用例描述和 Given / When / Then 验收标准,可直接进入待办列表进行估算和排期。
3. 拆分质量验证清单: 从 5 个问题校验拆分质量——是否独立交付用户价值、能否独立开发、能否独立测试、是否小到 1-5 天工作量、合并后是否等于原故事,帮助规避水平切片、过度拆分、硬依赖等常见反模式。

常见问题

用户故事太大、一个迭代做不完怎么办?

把故事原文交给这个技能,它会按 8 种拆分模式逐一套用: 先看故事里是否包含多个顺序步骤(工作流步骤),再检查是否有不同业务规则、多种数据类型或多组 When/Then 验收标准。一旦找到适用的模式,就沿这个切面把故事切成若干个小故事,每个都能在一个迭代内完成并单独发布价值。

为什么不能把故事拆成"前端一个故事、后端一个故事"?

这是典型的水平切片反模式: 前端故事和后端故事单独都不交付用户价值,还互相形成硬依赖,拖慢整体交付。正确做法是纵向拆分——每个小故事都包含完整的前后端工作,完成后用户能直接感知到价值。该技能内置了反模式检查,输出前会逐条验证每个拆分是否真正交付用户价值,并确保每个拆分有独立的"以便于"结果,而不是只切了动作没切价值。

拆分后的每个故事应该多小?拆到什么程度算合适?

经验标准是 1-5 天的工作量,并且每个故事能独立开发、独立测试、独立交付,合并起来要完整覆盖原故事的范围。注意不要过度拆分——一个本来 2 天就能完成的故事没有必要拆;如果需求本身有大量未知(比如"AI 智能推荐"这类模糊需求),技能会先用微小发现实验(TADs)做小规模验证、消除不确定性,再回来写正式的用户故事。