用户故事是了解需求的工具，对于做计划而言，了解需求只需要到能够估算它的程度就足够了。不需要了解需求的所有细节，但必须知道存在很多细节，也必须要了解细节的大致分类，但是不必知道特定的细节。

用户故事就是正在进行的关于需求的谈话的助记符。它是一个计划工具，客户可以使用它并根据需求的优先级和估算代价来安排实现该需求的时间。

用户故事的定义：在识别用户需求时，用一段简短的、表达一部分可演示的功能的日常用语来描述的文本信息。“一个用户故事描述了将会给软件或系统的最终使用者或是采购者带来价值的功能”——Mike cohn《用户故事应用》。

用户故事的格式：作为<用户>，我想要<愿望>，这样我就可以<收益>。（或者用XP提倡的：直接为每个故事取一个简单的名称，以及简短的描述或图示。）用户故事的核心是“我想要”部分。用户故事的格式帮我们回答了几个经典的问题“谁”，“什么”，“为什么”：谁=角色，什么=愿望，为什么=收益。用户故事是一个快速将干系人需要的结果文档化的快捷方式 ，不需要陷入书写详细需求说明书的泥潭里。

用户故事的基本原则：
1、包含刚刚够用的信息，不应该花费团队太多天的时间来实现。
2、不应该有难懂的技术术语，它需要能够被程序员和干系人都理解。

用户故事INVEST原则:
独立的（Idependent）：一个用户故事应该是独立的并且是完整的，不依赖于其他任何用户故事。
可谈判的（Negotiable）：用户故事是且来引导团队跟干系人之间对话和谈判的介质。在任何时候，用户故事都可以被改写甚至丢弃。一个用户故事不会像石头一样固定不变，直到它将要在接下来的Sprint里被实现。
有价值的（Valuable）：一个故事需要将会价值给干系人（不管是最终用户还是采购者）。
可估算的（Estimable）：团队需要能够粗略地估算出完成用户故事所需要的工作量的规模。
小规模的(Small)：一个用户故事可以以一个大的“占位符”开始其生命周期。随着时间的推移，当人们对用户故事所表达的愿望的复杂度更加了解时，这个较大的“占位符”就将被拆分成小的用户故事。当最重要的那些用户故事将进入Sprint被实现并交付时，它们需要变得足够小，这样才能在一个Sprintj里被完成。
可测试的(Testable)：一个用户故事必须提供必要的信息，清楚地界定了故事的验收标准，这样才能在它完成时判断是否验收。

尽管用户故事的核心只是用一行字描述来总结了愿望，最重要的部分却是它的可视化。用户故事鼓励一种可以通过团队和干系人之间的交谈和确认反复地优化软件的流程。细节在交谈中产生，成功的标准记录在确认信息里。
参考书籍：《解析极限编程》《敏捷软件开发：原则、模式和实践》《敏捷可执行需求说明》