用户故事，史诗故事和主题故事

敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项（Product Backlog）中的特性描述文字，来替代传统长篇大论的需求文档。

我们发现用户故事是最好的描述方式，这种形式能够捕获到特性足够多的信息，并促进产品负责人和团队在后续进一步交流。用户故事是从人（通常是系统的用户或者客户）渴望新功能的视角来对特性进行描述。

用户故事一般会采用以下这种简单格式进行描述：“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性，但只要能围绕着故事进行交流，用户故事可以以任何形式进行描述。

用户故事可以呈现为不同的规模。小的故事，就称为“用户故事”，能够在冲刺（Sprint）中很好的得到理解和执行——例如：“作为经理，我希望能够以分页的形式看月度销售报表，这样我就能快速查阅文档的各部分内容”。

大型用户故事通常被称为“史诗故事”。我们把某个故事称为“史诗故事”时并不存在什么神奇的门槛，只是意味着“这是个大型用户故事”而已。

史诗故事通常需要花费1到2个Sprint来开发和测试。它们通常范围比较大而细节描述较少，
在团队开发前通常需要拆分成多个更小的故事。

构造月度销售报表科目时，可能有这样的史诗故事：“作为销售经理，我希望能分区域看销售数据”。

我们把大型故事称为“史诗故事”以便交流。我喜欢把它类比为电影。如果我告诉你某某电影是一部“动作冒险电影”，这会向你传递电影的某些信息，例如可能会有些追车镜头，可能会有些枪战镜头，等等。类似的，称一个故事为“史诗故事”也能传递额外的意义。

如果你问我昨天是否有时间写关于系统月报部分的用户故事。我回答说“写好了，但几乎都是史诗故事。”。那就是告诉你我确实写了用户故事，但是我还没来及把它们拆分成足够小和可以直接执行的故事。

当谈论用户故事时，通常还会用到另一个术语——“主题故事”。主题故事是对相关的用户故事的集合。我写了一组关于月度报告格式化的故事，这些故事可以给出一个主题——“月度报告格式化”。我们可以围绕着这些故事进行抽象（或者按字面）概括，形成一个组，即主题故事。

采用上面的电影分类，我已经把我DVD架上所有詹姆斯·邦德的电影都归到一起，形成一个主题。

在Scrum中，用户故事、史诗故事和主题故事只是我们用于帮助简化Scrum团队交流描述的术语而已。如果追溯到早期的极限编程团队，这些术语是有着标准含义的。以行业标准方式来使用，也是一种不错的用法。

但如果这些对你们没有用，你们也可以自行定义。别忘了，术语只是术语，用户故事最重要的还是能促进交流。