1.背景
在构建数据仓库和商业智能系统（下面简称DW/BI系统）时，开发者们总是会以数据为中心，首先从数据层面上进行大量的工作，他们甚至错误的认为，只要确保数据的正确，就可以满足未来一切可能的用户需求。但实际上，这样的DW/BI系统往往不能很好地解决具体的商业问题，因为这类系统并不是建构在对用户需求的了解上，也没有尽早地向用户传递商业价值，以至被用户所抛弃。
而敏捷分析强调的是价值驱动，在整个开发的过程中，开发者迫切地期望开发出能满足用户需求、解决商业问题的可用功能，数据只是服务于这个目标。因此，敏捷分析的第一步应当是广泛而快速地收集用户需求，并加以组织，然后将其转化为确实需要开发的高价值功能。要做到这点，就需要使用到敏捷开发中的用户故事（User Story）。可以说，敏捷分析是以用户故事驱动的方法来构建DW/BI系统，而非数据驱动。
2.定义
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories."
3.译文
在与客户或产品负责人咨询交流后，团队划分了要完成的功能性增量工作被称为“用户故事”。
以上的定义可能稍微官方标准化，可以如下理解：
用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：
作为一个<角色>，我需要系统能够<做某事>，这样我可以<目标陈述>。
举例:
作为一个产品运营人员，我希望系统能够让我看到新登用户中只有一次会话的用户（DOSU: Daily One Session Users），这样我可以衡量新用户的质量。
当然，用户故事也可以按照如下的格式来表达：
为了实现<目标陈述>，作为一个<角色>，我需要系统能够<做某事>。
在这两个模板中，都包含有3个要素：
- Who：用户角色。
- What：通过系统完成的某项操作。
- Why（reason）：需要达成的某个目标（实现的商业价值）。
4.3C原则
用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
（1）卡片（Card）：通过将故事写在note card上面，除了故事本身的描述之外，还应该包括故事的时间点估计及对应的测试行为等等。用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
- 卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；
- 卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确保各方对故事的理解正确。
（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。用户故事划分以后是由开发人员通过编码实现，但是不能仅靠开发人员自测确认故事完成，需要的是一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。
5.INVEST原则
下一篇文章讲解
6.推荐阅读
1.INVEST in Good Stories, and SMART Tasks
