序言
用户故事是敏捷实践中一个十分重要的环节，它能帮助我们高效地收集客户真正的需求。软件开发都始于需求收集与分析，如果一开始的需求都弄错了，软件的成功则无从谈起。
另一个重要的环节是高效沟通，不论是开发团队与客户的沟通，还是团队内部人员之间的沟通。沟通可以使得客户和团队成员都朝同一个方向前进，更少的浪费、风险和成本。
什么是用户故事？
用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三个方面组成：
- 卡片（Card）：卡片代表客户需求，包含一份书面的故事描述，用来做计划和作为提示。
- 对话（Conversation）：有关故事的对话是需求的细节化，用于具体化故事细节。
- 确认（Confirmation）：验收测试，用于表达和编档故事细节可用于确定故事何时完成。
故事的使用
客户团队：专职人员，为开发人员排列优先级，回答他们所有问题，在软件完成时使用软件，并且写下所有的故事。客户团队中包含确保软件满足用户需求的所有人，意味着可以包括测试人员、产品经理、实际用户和交互设计师。
为什么客户团队而不是由开发团队来编写用户故事？
主要基于两个原因：首先每个故事必须用商业语言来写，而不是技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布。其次，作为主要的产品构想者，客户团队所处的位置最适合描述产品行为。
客户团队和开发人员一起选择迭代长度，可能一周到四周的时间。客户团队要确保项目能够达成交付所需产品的目标。一旦确定了迭代长度，开发人员就会估计每轮迭代中可以做多少事情，我们称之为速率（velocity）。每轮迭代开始前，客户团队可以在中途修正计划，当迭代结束后，我们可以得知开发团队的实际速率，然后用它代替估计速率进行估计。
什么是验收测试？
验收测试用来验证实现的用户故事是否符合客户团队的期望。测试工作可以包括从故事卡背面写下测试描述开始，将测试放入到自动化测试工具中的所有工作。
如何编写故事？
一个优秀的用户故事（需求）应该具备以下几个特点：
独立的（Independent）
应该尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致一些问题。出现依赖时，可以使用两种方法：第一，将相互依赖的故事合并成一个大的、独立的故事；第二，用一个不同的方式去分割故事。
可讨论的（Negotiable）
故事不是签署好的合同或者软件必须实现的需求，他们是可以讨论的。故事卡是功能的简单描述，细节将在客户团队和开发团队的讨论中产生。把故事卡用于提醒开发人员和客户进行关于需求的讨论，讨论中确定的细节将变成测试。
对用户或者客户有价值的（Valuable to Purchasers or Users）
应当尽量保证“每个故事对用户有价值”。最好的方法是让客户来编写故事（需求）。
可估计的（Estimatable）
当故事无法估计是因为开发人员不掌握所涉及的技术时，可以让一个或多个开发人员去实施极限编程（XP）中的探针试验（spike），限定一个最大时间量（称为时间箱，timebox），用这个时间量作为探针试验的估计，如此，一个不可估计的故事就可以变成两个故事：一个快速的探针故事（用来获取足够的信息）和一个故事（真正的实现功能）。
小的（Small）
故事的大小很关键，故事太大或太小，都无助于制订计划。合适的故事大小最终取决于团队、它的容量及所使用的技术。如果故事是很大的史诗故事（分为复合故事compound story和复杂故事complex story）则对故事进行分割。相同的，故事太小时，可以对故事进行合并。
可测试的（Testable）
故事必须是可测试的。成功通过了测试可以证明开发人员正确地实现了故事。不可测试的故事通常发生在一些非功能性的需求上，这些需求和软件有关，但不直接与功能有关。 （给故事加上注释最好的办法是给它编写测试用例）。
