Epic：把大想法变成
可验证的价值改变

先别急着统一口径：Epic 有两种常见用法

“Epic”不是 Scrum 官方规定的工件，也没有跨所有敏捷框架的唯一尺寸。公开资料中至少存在两种成熟但层级不同的用法。组织必须先说明自己在哪一层使用它。

Epic 在系统中的位置：连接方向，但不替代任何一层

一个常见层级是“战略主题 → Epic → Feature/实验 → Story → Task”，但它只是可选的组织方式，不是敏捷法则。每一层回答的问题不同。

组合层 Epic 要过四道门

合格不是“卡片填满了”，而是从是否配称，到能否退出，形成完整的投资与学习逻辑。

“做完”不等于“产生价值”：至少看四层证据

系统上线、流程发布、培训完成，只能证明产生了输出。价值通常要经过“可用 → 被采用 → 关键机制改善 → 经营或客户结果改变”。

同时设置护栏

目标指标说明想改善什么；护栏指标说明不能以什么为代价。例如增长不能以利润和库存健康恶化为代价，自动化不能以错误率和人工兜底失控为代价，短期交付不能持续透支平台稳定性和数据质量。

MVP 的正确问题

MVP（最小可行产品 / 最小验证）不是“完整项目的一期”或“把全部功能做 60%”。它是用尽可能少的投入，获得足以支持下一次投资决定的可信证据。它可以是人工服务、原型、影子运行、回测、小市场试验或受控产品增量。

怎样拆 Epic：沿价值和学习切，不沿部门切

好的拆分让每一片都能更早产生可观察的结果或关键证据；坏的拆分只是把同一批工作分发给不同职能，最后仍要全部完成才能验收。

Epic 最小卡片：够决策，不追求一次写完

模板的作用是暴露判断缺口，不是替代讨论。早期未知项可以明确标为假设或待验证，不要用虚假精确填满表格。

# Epic：用“结果假设”命名

## 1. 问题与目标对象
- 谁在什么场景遇到什么关键问题？
- 当前基线与证据是什么？

## 2. 战略与价值流关联
- 对应方向 / 目标：
- 主要改善哪条价值流的什么端到端结果：
- 为什么需要 Epic 级治理，而不是普通 Backlog：

## 3. 结果假设
- 如果我们【做出待验证的改变】，那么【对象】的【结果】将从【基线】改善到【目标 / 方向】，因为我们相信【关键机制】。
- 最危险、最需要证伪的假设：

## 4. 最小验证（MVP）
- 验证对象与范围：
- 计划获得的证据：
- 时间盒 / 阶段投入：
- 本阶段明确不做：

## 5. 度量与护栏
- 交付证据：
- 采用证据：
- 领先证据：
- 结果证据：
- 不能伤害的护栏：

## 6. 责任、依赖与决策
- 结果责任：
- 推进责任：
- 关键依赖：
- 价值 / 组织 / 技术 / 投资分别由谁决定：

## 7. 决策与退出
- 什么条件下继续或加码：
- 什么条件下调整或转向：
- 什么条件下暂停或停止：
- 验证结束后由谁承接：

评审不问“写全了吗”，先问这十二个问题

八个高频误区

术语速查

来源、适用边界与独立判断

本页优先使用框架官方或专业组织的一手定义，并明确区分“来源这样定义”与“所有组织都必须照搬”。

1. Agile Alliance — Epic：团队层经典定义、收益、适用场景与过度复杂化风险。
2. The 2020 Scrum Guide：Scrum 官方工件、Product Backlog、Product Goal 与持续细化；Epic 并非 Scrum 规定术语。
3. Scaled Agile Framework — Epic：组合层重大举措、MVP、轻量商业论证及两类 Epic。
4. SAFe — Lean Portfolio Management：价值流投资、组合看板、Build–Measure–Learn、WIP 与阶段决策。
5. Atlassian — Epics, Stories, and Initiatives：常见工作层级及“结构需按组织情境调整”的工具实践。