epic原意为“史诗”，在敏捷用语中是一个大user story，需要被为分解为多个独立的小user story。通常，敏捷团队这样做，是为了得到简单、易管理的小user story，以便其可以在一个单独的sprint中被完成。

满足sprint的任务分配，并不是需要进行epic分解的唯一原因。客户想要的通常是很复杂的，需要被拆解成小的组件才能被彻底理解与执行。因此，让功能变得明确，则是需要进行epic分解的另外一个考量。第三个考量是“由谁完成工作”。如果一个user story需要两个以上的敏捷团队去完成，这样的story就应被视为一个epic而继续被分解为多个user story，使得每个团队都有各自的story。

通常，epic的分解是由PO持续在backlog梳理、发布或产品策划的时候进行的。分解的过程通常是迭代的。PO可以指定一个feature分配给团队。团队可以将其作为epic，并进一步分解。敏捷的实践者没有统一的标准来衡量user story和epic，只是常规地认为epic可以贯穿多个sprint，但user story不可以。

运用CMMI增强epic

Epic是大型的user story，在分配到sprint backlog之前，需要进一步精炼。尤其是在项目早期，需求的不确定性促使我们需要记录相对笼统的已知。这便产生了敏捷项目的epic。尽管敏捷正视了需求的不确定性与变更，但这并不意味着敏捷鼓励混乱地对待需求。如果负责进行需求定义的人，不能掌握结构化需求开发的方法，那么他写出来的epic就会可想而知。

CMMI在需求开发过程域中的特定目标与实践，可以为创建epic与user story提供清晰的过程，让产品的backlog变得💪🏼“健壮”💪🏼起来。

比如：

• 在创建产品backlog时，确保考虑到产品需求的所有可能来源（除了你的客户，还可能包含客户的用户、第三方管理机构等）。项目早期就缺失了重要的需求输入，会对项目的未来造成极大的影响。

• 确保相关干系人均参与到创建和评审epic、user story的过程中，以减轻sprint中潜在的误解和返工。

• 确保驱动sprint策划的产品backlog经过分析和验证。团队清楚的知道如何测试或验证backlog。

敏捷项目的目标之一，是能够快速、有效地响应项目生命周期中，不可避免的变化。这些变化包括项目时间变更、团队成员变更、信息需求变更，以及最具破坏性的需求变更。

Scrum是一个轻量级的项目管理框架，它将具体执行的细节留给了团队。这既是空间，也是空白。CMMI中的需求管理过程领域提供了许多行业最佳实践，可以帮助敏捷团队在借助backlog处理需求时，不会遗漏重要的事项。

下面是一些例子：

• 在需求干系人之间，通过验收标准与开放的沟通渠道，确保epic和user story的清晰度。敏捷需要透明性，而CMMI加强了这一需求，特别是围绕需求。

• 强化“团队的工作承诺是产品开发的关键部分”的理念。CMMI阐明了承诺对于需求变更也很重要，这一点经常被忽略。

• 无论需求是何种形式，均需要对需求可追溯性设置期望。在敏捷项目中，实现良好的可追溯性可能很困难，尤其是在使用纯可视化管理方法的情况下。

当反馈循环很短且学习发生时，敏捷团队就会茁壮成长。需求开发中的信息组件，是学习如何确保产品backlog中的epic和user story的完整性和健壮性的极好来源。而需求管理中的信息组件，对产品backlog中的epic和user story不可避免的变化，进行了强有力的管理。

需求开发

需求管理