用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。
用户故事应该具备以下特点：
1) 独立的：应该避免故事间的项目依赖。在对故事排列优先级时，或者做计划时，故事间的相互依赖会导致问题。
2) 可讨论的：故事不是签署好的合同，故事是功能的阶段描述，它提供了适量的信息给开发人员和客户团队，提醒他们在以后进行关于需求的对话。它并不是需求本身，因而不需要包含所有细节。
3) 对用户或客户有价值的：每个故事必须对用户有价值，因此应该避免那些只对开发人员有价值的故事，例如技术和实现细节，用户界面等。保证每个故事对客户又加重的最好方法是让客户来便携故事。
4) 可估计的：对于开发人员来时，应该能够估算故事的大小。如果故事太大而无法进行估算，则需要分解成更小的故事。但有时也需要史诗故事作为占位符或提示。
5) 小的：故事的大小很关键，故事太大或太小，都无助于制定计划。史诗故事在执行前，需要分成更小的故事。合适的故事大小取决于团队，它的容量及所使用的技术。
6) 可测试的：故事必须是可测试的，成功通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员将无法知道什么时候才算完成了代码。
用户故事的优点有：
1）强调对话交流而不是书面沟通：
使用用户故事的目的并不是让我们事无巨细的记录下想要的特征，而是提醒开发人员在将来需要与客户进行沟通与交谈。相较于追求完美的需求文档，更有价值的是运用频繁的沟通来加强恰当的故事。
2）容易被用户和开发人员理解：
用户故事中通常没有太多的技术术语或领域术语，用户和开发人员都可以理解。另外，用户故事通常实在用户故事会中讨论出来的，参与者能够从用户故事清楚的回忆起讨论清楚的情节。
3）大小适合于做计划：
与用例和场景不同，用户故事的大小可以掌控，可以很方便的用于发布规划以及进行编程和测试。
4）适用于迭代开发：
用户故事与迭代开发相辅相成，我们并不需要在开始编码之前写出所有用户故事。 我们可以写出一部分故事，就进行编码和测试，然后按照需要的节奏重复这一过程。写故事时，我们可以按照我们认为合适的粒度去写。正式由于我们很容易对故事本身也进行迭代，因此用户故事很适合迭代开发。
5）鼓励推至考虑细节
团队可以费城迅速的写出数十个用户故事，让大家对系统有一个整体概念，然后就讨论前几个故事的细节并开始编码，而其他故事在后来对于开发进程变得重要时，才补充更多细节来代替简单的描述。这远比被迫先完成一份完美的软件需求文档进展快许多。
6）鼓励参与性设计
把交谈的中点从系统特性转移到用户使用该系统目标的故事，会使讨论变得有趣，激发用户的积极性，成为软件设计的参与者。
如何编写优秀的用户故事
1）从目标故事开始：在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。最好的办法是考虑每一个用户角色，了解用户使用软件的目标，然后从目标开始分析出新的故事。
2）切蛋糕：当面临一个大的故事时，通常有许多方法可以将它分解成较小的故事，比较好的方式是让每个故事都提供某种程度的完整的功能，即“切蛋糕”。这样的好处是，首先在开发中尽早设计软件应用架构的每一次能够有效降低最后时刻才发现层次架构方面问题的风险；其次，尽管不十分完美，即使只提供部分功能，但只要发布的功能可以跑，就可以把程序发布给用户使用。
3）编写封闭的故事：一个封闭的故事是指随着一个有意义的目标的实现而结束的故事，它能让用户使用后觉得她完成了某个任务，带给用户一种成就感。一个大的非封闭的故事，可以分解成多个小的封闭故事。
4）约束卡片：对于一些必须要遵守而不需要直接实现的故事，尽管它不需要被估算，也不会像普通故事那样呗安排到迭代中，但他们仍然很有用。可以把他们放在醒目的地方，提醒开发人员不要违反约束，并针对约束编写验收测试来确保系统满足约束。
5）根据实现时间来确定故事规模：应该讲注意力放在那些即将发生的事情上，而不是放在更远的将来才发生的事情上。类似，对于故事而言，要基于故事实现的时间跨度，以不同的层次来编写故事。对于即将要实现的故事，它们的大小应该适合安排进下几轮迭代中；而对于更遥远的故事，他们可能会更大，且精确度更低。
6）不要过早涉及用户界面：由于用户界面说明或暗示了解决方案以及细节，因此用该尽量让故事不包含用户界面，而只是描述功能。
7）不是所有需求都可以写成故事：尽管用户故事是一个非常灵活的格式，可以很好的描述许多系统的很多功能，但它不是万灵药。如果发现系统某些方面更适合用其他表达方式，尽可放心使用。
8）在故事里包括用户角色：如果项目团队已经识别出用户角色，那么在别写故事时使用实际的用户角色而不是简单的“用户”。这使得开发人员能够联想实际的，真切的用户，开发出满足用户需求的软件。
9）至为一个用户编写故事：当故事只为单一用户编写时，故事的可读性通常是最强的。
10）以主动语态填写
11）由客户编写：在理想情况下，故事应由客户编写，这是客户的职责，不应转嫁给开发人员。另外，因为客户有责任排列故事的优先级，所以客户理解每个故事时至关重要的，而要做到这一点，亲自编写无疑是最好的方法
12）不要给故事编号：故事之前是独立的，没有先后顺序的，因此不应该给故事编号，如果有必要，可以给故事加一个简短的标题，并在其余的故事描述文本中使用这个标题作为缩写。
13）不要忘记意图：不要忘记，故事卡的主要目的是用来提醒开发人员和客户团队就功能进行讨论。因为仅仅是一个提醒，就要保持它的简洁性。可以加入必要的细节以便联系到继续对话的切入点，但是不要再故事中加入太多细节并以此取代对话。
用户故事不良征兆
1） 故事太小，导致经常需要调整估算；
2）故事之间相互依赖，导致很难做迭代计划；
3）镀金，开发人员在迭代中实现计划外的功能；
4）细节太多，导致前期花太多的攻速整理故事细节，或者写故事而不是讨论故事；
5）过早考虑用户界面细节；
6）想得太远，追求在前期花很多功夫捕捉故事相关的所有细节；
7）故事划分变化频繁；
8）客户难以为故事安排优先级，这可能是由于故事太大或包含了体现不出商业价值的用户故事；
9）客户不愿意写用户故事，也不愿意为故事安排优先级；