编写一个优秀的用户故事
尽量避免故事之间的依赖。因为在对故事排列优先级或者做计划的时候，故事之间的依赖会导致一些问题。
如“图片放大”与“图片缩小”有依赖，“放大”的优先级高于“缩小”的优先级，当客户团队选择了“放大”后，而不能缩小，就会有问题。
故事是可以讨论的。它不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。
如果在编写故事的时候已经知道一些重要细节，可以在故事卡上注释，但不能有太多注释和细节，这会导致一种错觉：故事卡反应了所有细节，没必要再讨论了。
故事卡包含信息：①一两句短语，用来提醒开发人员和客户进行对话；②一些注释，用以表明在对话中亟待解决的问题。
Valuable to Purchasers or Users
假设一个开发团队正在构建一个支持大量用户的软件，可能在公司5000台电脑上实施。
对开发有价值的故事：①所有的错误处理和记录赢在一些列公共类中完成。
以上关注技术和实现细节，并不能体现对客户或用户的价值，很难排列优先级。做如下转换会更好：
①所有的错误应以统一的方式呈现给用户并作记录。
保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。
对开发人员来说，能估算故事大小，或者能把故事变为可用代码的时间量是很重要的。
一般有3个原因导致故事不可估计：
1.开发人员缺少领域知识。——可以和写故事的人一起讨论。
2.开发人员缺少技术知识。——可以实施极限编程中的探针实验。
3.故事太大了。——分解成更多的小故事。
故事大小很关键，太大或太小都无助于制定计划。
对于太大的故事，进行分割。史诗故事通常分为两种：复合故事和复杂故事。
复合故事，由多个小故事组成，可以对较小的故事进行整合分解。
复杂故事，如果因为不确定性而复杂，可以分成两个故事，一个做调研的故事和一个开发故事。
对于太小的故事，可以进行合并。
故事必须是可测的，成功通过测试，说明开发人员正确的实现了故事。
通常不可测的故事发生在一些非功能性需求上，如：
①用户绝不需要花很长时间等待窗口出现。
可以改为：
在95%的情况下，新窗口会在2秒内打开。
来源 | 网络 侵删