2.3. 对用户或客户有价值的

“每个故事必须对用户有价值”，这句话说起来很诱人。但是许多项目中包含了对用户没有意义的故事。

要记住用户（软件的使用者）和客户（购买软件的人）之间的区别。

假设，一个开放团队正在构建一个支持大量用户的软件，可能需要在公司内5000台电脑上实施。像这样的客户比较关心5000台电脑是否在使用同样的软件配置。这就会产生一个例如这样的故事：“所有的配置都从一个中心读取”。但是用户不关心配置信息在哪里存储，但是购买者可能比较关心。

隐含测试用例的细节要和故事本身分开

用Visa信用卡、万事达信用卡和运通卡测试(通过)
用大来卡（Diner’s Club)测试（失败)
用有效、无效和丢失卡ID号的信用卡测试
用过期卡测试
用高于100元和低于100元测试

类似，下面的故事显示客户在购买时要考虑的价值，却不是用户所需要考虑的。

• 整个开发过程中，开发团队要提供符合ISO9001标准审核的文档
• 开发团队要按照CMM3级的标准来构建软件

应当避免那些只对开发人员有价值的故事。

例如，应该避免下面类似的故事。

• 所有的数据库连接要通过一个连接池
• 所有的错误处理和记录应在一系列公共类中完成

这些故事都在关注技术和实现细节。很可能这些故事背后的想法是好的，但是故事的编写方法应当体现对客户或用户的价值。这样使客户团队能方便的在开发中对那些故事排优先级。

更好的故事版本

• 这个应用软件，最多50位用户能使用一个5用户的数据库许可
• 所有的错误应以统一的方式呈现给用户并做记录

同样，也应当避免在故事中出现用户界面和技术方面的定义。

保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。开始时，客户一般都会觉得不舒服，可能因为他们觉得写下了的东西都有可能成为未来对他们不利的证据（“好吧，需求文档并没有这么说…….”）。但是故事只是为了提醒他们需要之后进行需求讨论，而不是一个正式的承诺或某个功能的具体描述。大多数的用户一旦接受这个概念，就会开始自己写故事了。