故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。客户团队应包括能确定软件最终用户需求的人，可能包括测试者，产品管理者，真实用户和交互设计师。因为他们处于描述需求的最佳位置，也因为随后他们需要和开发者一同设计出故事细节并确定故事优先级。
问题上下文
我们知道用户故事可以解决需求问题时，那如何写好用户故事成为了一个问题，什么是好的用户故事，好的用户故事该怎么写？
解决方案
为了构建好的故事，我么嗯关注六个特征。一个优秀的用户故事应该具备以下特点：
- 独立的
- 可讨论的
- 对用户或客户有价值的
- 可估计的
- 小的
- 可测试的额
独立的
我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致一些问题。例如面积色客户团队已经选择了一个高优先级的故事，但它对一个低优先级的故事有依赖，这就会出现问题。故事间的相互依赖会导致工作量估算变得更加困难。
出现这种依赖时，通常我们可以通过两种方法来减少依赖性：
- 将相互依赖的故事合并成一个大的、独立的故事
- 用一个不同的方式去分割故事
假若你不想合并故事，但又找不到好的方法来分割它。还可以使用一个简单的方法，即再故事卡上加上两个估计：当该故事将早于另一个故事实现时，一i个较高的估计；当该故事将晚于另一个故事实现时，一个较低的估计。
可讨论的
故事是可以讨论的。他们不是签署好的合同或者软件必须实现的需求。 故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本身，因而它们不需要包含所有的相关细节。然而。如果我们在编写故事的时候已经知道了一些重要的细节，那么应该在故事卡上以注释的形式记录下这些细节（难点在于掌握如何恰如其分地包含细节）。
一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。若我们把故事卡用于提醒开发人员和客户进行关于需求的讨论，那么故事卡包含下面的信息就变得有意义。
- 一两句短语，用来提醒开发人员和客户进行对话
- 一些注释，用以表明在对话中亟待解决的我问题
在讨论中确定的细节将变成测试。如果我们使用的是纸质卡片，那么测试可以被标注在卡片背面；托斯电子文档，可以标注在合适的地方。
对用户或客户有价值的
“每个故事必须对用户有价值”，听起来很诱人，但这是部队的。许多项目包含对用户没有意义的故事。同时要记住，用户（软件的使用者）和客户（购买软件的人）之间的区别。 故事的编写应当体现对客户或用的价值，避免在故事中出现技术和实现细节。想保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。开始时客户一般都会感觉不舒服，可能因为开发人员以前总是令他们觉得他们写来的任何东西都是可能成为未来对他们不利的证据。 故事卡只是提醒他们需要之后进行讨论的需求，而不是一个正式的承诺或某个功能的具体描述。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可估算的
对开发人员来说，能估算故事的大小，或者是把故事变为可用代码的时间量是很重要的。一般有游戏啊3个原因会导致故事不可估计。
- 开发人员却二嫂领域知识
- 开发人员缺少技术知识
- 故事太大了
首先，开发人员可能缺少领域知识。但如果开发人员不理解故事，他们应该和写故事的客户一起讨论。同样，没有必要理解故事的额所有细节，但是开发人员需要对故事有个大概的了解。
其次，故事无法估计是因为开发人员没有掌握所涉及的技术，团队里没有人有相关经验，无法估算这个任务。在这种情况下们可以让一个或多个开发人员去实施极限编程中所谓的探针实验。探针实验本身总是会限定一个最大时间量，用这个时间量作为探针实验的估计。 这样一个不可估计的故事就变成了两个故事：一个快速探针故事（用来获得只够的信息）和一个故事（真正实现功能）
最后，如果故事太大，开发人员可能也无法进行估算。此时，若要估算它，及要把它分解成很多个更小的故事。当然，有时编写例如“一个找工作的人可以找到一份工作”这样的实施故事也是很有用，因为它们可以作为系统中有待讨论的一大块功能的占位符或者提示。 如果希望暂时不细化系统的一部分功能，可以考虑写一两个史诗故事。也可以给史诗故事一个大的比较虚的估计值。
探针实验，是一个简短的实验，用于研究应用程序的某一个方面。在做探针实验的时候，开发人员不应该做十分深入的研究，只要能够对大体了解足够信息来估计这个任务即可。
小的
有些故事可能太大，有些可能太小，有些刚刚好。故事的大小很关键，故事太大或太小，都无助于制定计划。使用史诗故事来开展工作会很困难，因为它们通常包含多个故事。史诗故事需要分成更小的故事。合适的故事大小最终取决于团队、它的容量及所使用的技术。
分割故事
史诗故事通常分为一下两种：
-
复合故事
复合故事是由多个小的故事组成的史诗故事。一般有很多方法来分解一个复合故事。如按照“创建”、“编辑”和“删除”这些动作来分解故事；根据数据边界来分解。
-
复杂故事
不同于复合故事，复杂故事是其本身就很大且不容易分解的故事。如果一个故事因为不确定性而复杂，可以将它分成两个故事：一个做调研的故事和一个开发故事。
对无法估计的故事进行分解，需要好处是允许客户把调研工作从新功能中分离出来，以便于对调研工作排列出优先级。如果客户只列出这个复杂故事来排列优先级，且对它有一个估计，那么她可能会错误假设此新功能能实现的大致时间表，并以此来排列故事的优先级。 相反，如果客户有一个调研故事和一个功能故事，她必须在两个选择中做出决定，在这一轮迭代中加入调研故事，不增加新的功能；或者加入一些其他故事来增加新的功能。
合并故事
有时候，故事太小了。对于太小的故事，开发人员去实施该故事的时间比去写或者估计的时间可能更短。对于这样微不足道的小故事，在极限编程的团队中，一个比较好的方法通常是将其合并到需要半天或几天完成的故事中。给合并后的故事明明后，就可以同其他故事一样去计划实现它。
一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试的
故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
无论什么时候，只要有可能，就要把测试自动化。这意味着我们要争取99%都自动化，而不是10%。能自动化的测试基本上总是比你认为的要多。但产品时增量开发的，很多东西变化得很快，昨天能工作的代码，今天就会出现问题。只是需要自动化测试来帮助你尽早发现这些问题。
实际情况中，总有极小部分的测试是不能进行自动化测试的。例如。“一个新用户不经过培训就能完成一般的工作流程”这个用户故事可以测试，但是不能进行自动化测试。测试这个故事需要一个人为因素专家设计一个测试来观察一批随机的典型新用户。这种类型的测试可能是耗时且昂贵的。但是这个故事是可测试的，而且可能适合某些产品。
总结
- 理想情况下，故事之间是对你的。有时很难做到这一点，当我们要经历实现这一目标。故事之间的交付顺序应该是无关的，可以任意一个故事来实现。
- 故事细节由用户和开发人员讨论得出
- 故事应该很清晰地体现出对用户或客户的夹子。最好的做法是让客户编写故事
- 故事可以注释一些细节，但是过多的细节会使故事难以理解，有可能给人一种开发人员和客户无需交谈的错觉
- 给故事加上注释的最好方法是给它编写测试用例
- 如果故事太大，复合故事和复杂故事可以分成几个小的故事
- 如果故事太小，介个小故事可以合并成一个较大的故事
- 故事应该是可以测试的
