用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事应该有以下三个方面组成。
- 一份书面的故事描述，用来做计划和作为提示。
- 有关故事的对话，用于具体化故事细节。
- 测试，用于表达和编档故事细节且可以用于确定故事何时完成。
二、使用故事的过程是怎么样的？
相较于过去的项目，使用故事的项目会有不同的感觉和节奏。使用传统的面向瀑布模型的过程会有一个书写所有需求、分析需求、设计方案、编码、最终测试的周期。在这样的过程中，客户和用户只在开始的时候参与进来写需求，在结束的时候验收软件，但用户和客户在搜集完需求后到验收之间的这段时间几乎都不参与。如今，我们已经知道这种方法是行不通的。
编写用户故事就需要让客户团队参与进来，客户团队可以包括测试人员、产品经理、实际用户和交互设计师。为什么要让客户来编写故事？首先，每个故事必须用商业语言来写，不是技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布，作为主要的产品构想者，客户团队所处的位置最适合描述产品行为。
三、好故事的六个特征
1.独立的(Idependent)
我们要尽量避免故事间的想互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致一些问题。例如，假设客户团队已经选择了一个高优先级的故事，但它对一个低优先的故事有依赖，这就会出现问题。
2.可讨论的(Negotiable)
故事是可以讨论的。它们不是签署好的合同或者软件必须实现的需求，故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生，因为故事卡的作用是提醒客户团队和开发团队在以后要进行关于需求的对话，它并不是具体需求本身，因而它不需要包含所有的相关细节。然而，如果我们在编写故事的时候已经知道了一些重要的细节，那么应该在故事卡上以注释的形式记录这些细节。
3.对用户或客户有价值的(Valuable to purchasers or Users)
“每个故事必须对用户有价值”，这话说起来很诱人。但那是不对的。许多项目包含对用户没有意义的故事。要记住用户和客户之间的区别。假设一个开发团队正在构建一个支持大量用户的软件，可能需要在公司内5000台电脑上实施。像这样的客户比较关心 5000台电脑是否在使用相同的软件配置。
4.可估计的(Estimatable)
对开发人员来说，能估算故事的大小，或者是把故事变为可用代码的时间量是很重要的。这个对于整个项目管理也是非常重要的。
5.小的(small)
故事的大小很关键，故事太大者太小，都无助于制订计划。那只能将故事重新分解或合并。合适的故事大小最终取决于团队、它的容量及所使用的技术。
6.可测试的(Testable)
故事必须是可以测试的。成功通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员怎么知道他们什么时候才算是完成了代码？
我也曾经写了很多不规范的故事卡，而且大多数都是这样，正是因为我对用户故事的理解不够。