第二章：编写故事
1.独立的
我们应当尽量避免需求之间的相互依赖，需求之间的相互依赖会导致一些问题，如果一个高优先级需求对一个低优先级需求有依赖，那么显然会出现问题。同时需求间的依赖也会是估计变得更加困难。假若你不想合并故事，但是又找不到好的方法合并它，可以在需求上加上两个估计：当该需求将早于另一个需求实现的时候，一个较高的估计，当该需求晚于另一个需求实现的时候，一个较低的估计。
2.可讨论的
需求当时是可以谈论的，既然都可以变，那么讨论又算什么呢？当然，我们在编写故事卡的时候也需要注意，不能将太多的细节写在故事卡上，让开发者过于关注本不应该太关注的细节，同时也会让开发人员产生这样一个错觉：没有必要和客户进行进一步的讨论了，细节太多人。
3.对用户或者是客户有价值的
很明显故事卡内容应当是对用户或者客户有价值的，对开发人员的价值是故事卡不需要的，如果有，那他便不是一个好的故事卡。、
4.可估计的
对于开发人员来说，估计需求所需要的时间是重要的。当遇到一下三种情况的时候，恐怕估计显得尤为困难（1）开发人员缺少领域知识（2）开发人员缺少技术知识（3）故事太大了。其实这三点都可以归类为一点，就是这个涉及知识盲区了，对于未知，如何进行估计？
5.小的
对于史诗故事，可以分为两种（1）复合故事（2）复杂故事。前者是由多个小故事组成的史诗故事，比如发布简历的时候实际上包括以下几点：（1）简历包含的内容有……（2）设置简历为非激活状态（3）多份简历（4）修改简历（5）删除简历，当然这些故事显然也是十分的小，我们则需要合并。而后者则是本身很大且不易分解，例如：公司可以使用信用卡支付发布职位的费用，而这个故事则需要这样分解：（1）调查研究网络上处理信用卡的相关技术（2）用户可以用信用卡收费，第一个故事会让开发人员实施探针实验，而这些故事这很难故事多久才能完成，当然如果将调研放在迭代中呢？
6.可测试的
需求必须是可测试的，没有测试，开发人员如何知道是否完成了？当然我们在测试中指标也需要定性的表示，而不能使用“绝不”，“很长时间”之类的话，不如试试“在95%的情况下，新窗口会在2秒内打开”吧。