最近朋友张三问我：“ 史诗、特性、用户故事，它们一定要关联到一起使用吗？ ”
我的答案是：当然不用。但是要真正解释清楚这个答案，我还需要对一些概念进行说明。
产品待办事项在Scrum Guide中，产品待办事项（Product Backlog）是产品所需的所有内容的有序列表，它是对产品进行任何更改的唯一入口。只要产品还存在，那么产品待办事项就存在，它会不断的变化，以适应产品的发展。产品待办事项中包含特性（Feature）、功能（Function）、需求（Requirement）、增强功能（Enhancement）和修复功能（Fix），然而在实践Scrum时，很多团队更习惯把它们替换成史诗（Epic）、特性（Feature）、故事（User Story）、任务（Task）和缺陷（Bug）。这些事项构成了将来对于产品的一系列改动。
随着产品的价值的增长，产品待办事项也将变得更大、更详尽。需求永远不会停止，这些需求可能来自业务场景、市场要求、技术更新等等。产品负责人需要在开发团队的协助下对产品待办事项进行细化，细化的内容包括添加明细、预估和排序。很多历史经验证明，一个产品只有20%的功能是常用功能，有40%的功能从未被使用，因此通过对产品待办事项的管理，可以有效的让开发资源聚焦在收益最大的工作上。
Sprint和增量Scrum的核心是Sprint，在一个固定的周期内，完成一个可以发布的产品增量。在Sprint开始时，首先要确定这个Sprint的待办事项，这些待办事项来源于产品待办事项，通常根据优先级而确定。在Sprint结束时，这个Sprint内完成的所有工作应该处于可用状态，这部分新增的产品特性、功能和缺陷修复是这个产品的一个增量，由产品负责人决定发布还是不发布。
增量是朝着目标又迈出了一步，它意味着产品待办列表中的一部分事项已经完成。一个Sprint接着另一个Sprint，一个增量接着另一个增量。
严格来说，Scrum中是没有用户故事的。用户故事的说法来源于Scrum的联合创始人Mike Cohen的山羊软件，它的核心在于从渴望新功能的人的角度对功能进行简短的描述。它通常遵循这样的模板：
作为<用户类型>，我想要<一些目标>，以便<一些原因>。
用户故事通常写在便签或者卡片上，供所有人进行讨论。它将编写复杂的需求文档转移到讨论需求上，这样的讨论可以有效的避免理解不一致的问题。
另外，用户故事应该足够小，小到一个Sprint内能够完成，我个人建议是在0-3天的工作量（使用时间形容规模是不恰当的，这里只是方便说明大小，感兴趣的朋友可以看我的上一篇文章），这样可以保证团队速度。
史诗史诗可以理解为是一个非常大的用户故事，可能需要数月才能完成，它无法放入一个Sprint中，却又是一个实实在在的需求。史诗就像是一个占位符，先放到产品代办事项中，在适当的时候，将它被拆分为很多小的用户故事，这些规模适当的用户故事将代替史诗放入Sprint中。
理解史诗有两个关键点：1. 它非常大， 2.还没想清楚里面的细节。
特性特性的规模介于史诗和用户故事之间，它是一组相关用户故事的集合，这些用户故事组成了一个完整的功能。当创建一个特性时，通常已经对细节思考的比较清楚，通过一个特性将相关的用户故事关联起来。
一个迭代并不意味着一个版本，有很多的场景中多个迭代对应着一个版本，在产品对外发布时，往往更关注的是特性的完成情况。
理解特性也有两个关键点：1. 它比较大，2.已经想清楚里面的细节。
史诗 & 特性 & 用户故事在复杂的业务场景中，史诗、特性和用户故事可以使产品待办事项更加的直观。它们可以建立一种树形的结构：
我回到张三的问题上。史诗、特性、用户故事，它们一定要关联到一起使用吗？当然不用。用户故事完全可以单独存在，史诗和特性的加入只是为了让需求管理更加的立体化。
最后，在Worktile Agile中，就是通过这样的方式来管理需求的，如果您正好需要这样一款敏捷研发的管理工具，不妨了解一下。