第二章编写故事首先书中指出了六个特征1.独立的2.可讨论的3.对用户或客户有价值的4.可估计的5.小的6.可测试的下面围绕这六个方面展开了讨论
独立的。文章指出要尽量避免故事之间相互依赖，否则在排列故事优先级时就会出现问题。而且导致难以进行准确的效率估计。所以为了解决这个问题，可以对故事进行合并，如果故事太大则进行再分割。如果不合并分割，有一个简单的方法，在故事卡上加上两个估计。该故事早于另一个故事实现时，一个较高的故事，晚于时，一个较低的估计。我解释的话就是，先做的部分，给的时间要多一点，后做的部分，少给一些时间，因为有些功能已经实现了。
可讨论的。故事是可以讨论的。故事是功能的简短的描述，而不是需求本身，所以故事卡中没有过多的需求，细节在客户团队和开发团队的讨论中产生。有时可以加一些重要的注释，但只是起引导作用不宜太多。
对用户或客户有价值的。许多项目包含对用户没有意义的故事。有些故事对用户没有意义但是对客户有意义。要避免那些只对开发人员有意义的故事。同时应当避免故事中出现用户界面和技术方面的定义。为了保证每个故事都对用户获知客户有用，最好让客户来编写。
可估计的。对于开发人员，估计故事大小或者把故事变成代码的用时非常重要。一般来说故事不可估计的原因有三个。1.开发人员缺少领域知识。2。缺少技术知识。3故事过于庞大。开发人员可能不会知道故事的所有细节，但是必须要了解大概。如果开发人员没有掌握开发需要的技术，他就无法估计项目。这是可以通过极限编程来测试时间。如果故事过于庞大可以分解这个故事。
小的。故事的大小适中很关键。用一个史诗级的故事开展工作，会带来很大的困难。我们可以把史诗级故事分割。史诗级故事分为两种1.复合故事2.复杂故事。复合故事是由多个小的故事组成的史诗级故事。复杂故事本身就是一个大的而难以分解的故事。复杂故事可以分为两个故事，一个做调研故事，一个做开发故事。有的时候故事太小了，我们可以把它合并到比较小的故事中去。
可测试的。故事是必须可测试的。成功通过测试才能证明开发人员完成了工作。否则无法判定工作的完成。不可测试的故事通常发生在非功能的需求上，这些需求和软件有关，单不和功能直接相关。比如软件好用。