第七章 优秀用户故事准则
经过前几章的学习，我们已经了解了什么是故事，如何拖网式捕捞以及编写故事，如何识别关键的用户角色以及验收测试在其中的作用。除此之外，我们还需要了解一些额外的编写优秀故事的准则。为了确定故事，我们需要从每个用户与角色使用系统的目标开始考虑，通过将目标细化，我们就可以以此衍生出更多新的故事。当面临一个大的故事时，由于故事的笼统性，我们需要将其分为更小的故事。这时就要注意，相比较于技术路线，贯穿应用程序层面的所有层面的故事才更加正确。这可以有效降低最后时刻出现层次架构方面的问题，还可以尽早完成交给用户。合理分配故事的大小，让故事具有封闭性，可以让用户拥有成就感。同时如果有项目领域和环境的需要，可以使用其他需求搜集或是文档技术来补充故事。
创建约束卡，将他们公之于众，同时还可以确保系统是否违反约束。按着当前的任务，将正在进行的功能细化，而对于那些尚未涉及到的，就可以编写宽泛、高层的故事。用户界面不易过早的涉及，容易给整个项目带来多余的影响。编写故事时还要注意：多使用主动语态；为单个用户编写；故事尽量简短；故事卡不要分号；最重要的还有，客户应是编写故事的人。
第八章 估算用户故事
项目的完成时间对于一个项目也是极为关键的，这就需要我们估算故事，有一个普遍使用的方法是使用：故事点。
故事点是故事复杂度、工作量或工期的相对估算。一般设为理想日或是理想周，借此来估算完成项目的时间。故事估算应该由整个团队集体完成，这样有利于今后的任务分配，也比个人估算更有效率。通常，我们通过和其他估算进行比较来进行三角测量。团队是否使用结对编程对故事点的估算没有影响。结对编程影响的是团队的效率，而不是他们的估算。估算之间并不是分与和的关系，小估算的和不等于总估算。而且，在估算这一事件中，开发人员应当承担起主要责任，邀请客户参加估算会议，询问故事细节，给出团队的诚实估算，这对今后的开发有至关重要的影响。
第九章 发布计划
制定发布计划，是我们指导整个开发流程的指挥棒。制定发布计划时，有必要知道客户预期的大致发布日期，同时还有故事的相对优先级。这两项可以帮助我们制定开发流程的细节：每个迭代的工作量，与之相关的迭代数，各个功能模块的优先级。通过优先级，我们就要以明确的顺序对故事进行排列，如第一个、第二个，而不是模糊的非常、十分等修饰词。故事的优先级主要由客户确定，但是也要考虑到开发人员的想法，因为技术是支持整个项目完成的核心。时间上，要以更准确地日历日来估算项目，而不是理想日，要考虑到开发过程中可能出现的各种情况，并以此判断团队的初始速率。