用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。
用户故事应该具备以下特点：
1) 独立的：应该避免故事间的项目依赖。在对故事排列优先级时，或者做计划时，故事间的相互依赖会导致问题。
2) 可讨论的：故事不是签署好的合同，故事是功能的阶段描述，它提供了适量的信息给开发人员和客户团队，提醒他们在以后进行关于需求的对话。它并不是需求本身，因而不需要包含所有细节。
3) 对用户或客户有价值的：每个故事必须对用户有价值，因此应该避免那些只对开发人员有价值的故事，例如技术和实现细节，用户界面等。保证每个故事对客户又加重的最好方法是让客户来便携故事。
4) 可估计的：对于开发人员来时，应该能够估算故事的大小。如果故事太大而无法进行估算，则需要分解成更小的故事。但有时也需要史诗故事作为占位符或提示。
5) 小的：故事的大小很关键，故事太大或太小，都无助于制定计划。史诗故事在执行前，需要分成更小的故事。合适的故事大小取决于团队，它的容量及所使用的技术。
6) 可测试的：故事必须是可测试的，成功通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员将无法知道什么时候才算完成了代码。
用户故事的优点有：
1）强调对话交流而不是书面沟通：
使用用户故事的目的并不是让我们事无巨细的记录下想要的特征，而是提醒开发人员在将来需要与客户进行沟通与交谈。相较于追求完美的需求文档，更有价值的是运用频繁的沟通来加强恰当的故事。
2）容易被用户和开发人员理解：
用户故事中通常没有太多的技术术语或领域术语，用户和开发人员都可以理解。另外，用户故事通常实在用户故事会中讨论出来的，参与者能够从用户故事清楚的回忆起讨论清楚的情节。
3）大小适合于做计划：
与用例和场景不同，用户故事的大小可以掌控，可以很方便的用于发布规划以及进行编程和测试。
4）适用于迭代开发：
用户故事与迭代开发相辅相成，我们并不需要在开始编码之前写出所有用户故事。 我们可以写出一部分故事，就进行编码和测试，然后按照需要的节奏重复这一过程。写故事时，我们可以按照我们认为合适的粒度去写。正式由于我们很容易对故事本身也进行迭代，因此用户故事很适合迭代开发。
5）鼓励推至考虑细节
团队可以费城迅速的写出数十个用户故事，让大家对系统有一个整体概念，然后就讨论前几个故事的细节并开始编码，而其他故事在后来对于开发进程变得重要时，才补充更多细节来代替简单的描述。这远比被迫先完成一份完美的软件需求文档进展快许多。
6）鼓励参与性设计
把交谈的中点从系统特性转移到用户使用该系统目标的故事，会使讨论变得有趣，激发用户的积极性，成为软件设计的参与者。
用户故事不良征兆
1 故事太小，导致经常需要调整估算；
2 故事之间相互依赖，导致很难做迭代计划；
3 镀金，开发人员在迭代中实现计划外的功能；
4 细节太多，导致前期花太多的攻速整理故事细节，或者写故事而不是讨论故事；
5 过早考虑用户界面细节；
6 想得太远，追求在前期花很多功夫捕捉故事相关的所有细节；
7 故事划分变化频繁；
8 客户难以为故事安排优先级，这可能是由于故事太大或包含了体现不出商业价值的用户故事；
9 客户不愿意写用户故事，也不愿意为故事安排优先级；