第10章 迭代计划
制定出上一章的成果发布计划，我们可以顺利地将粗细度的故事分配到多伦迭代中。多伦迭代是发布计划的进一步激化，但只在迭代即将开始的时候才开始做迭代计划。为此，迭代计划会议必不可少，客户以及团队的所有人员都要参与其中。在这一过程，各个人员仔细讨论每个故事，从故事中分解出任务，开发人员承担每个任务的职责。这个会议是客户为团队调整故事的最佳时机，但是切记项目团队不要随意被客户打乱开发计划。
任务的大小没有强制的范围（例如：3小时到5小时）。相反，从故事中分解任务，用来帮助估算或鼓励多个开发人员合作完成一个故事。并且要保证每个任务都有开发人员承担，不要遗漏或者丢失任何一项任务。每个开发人员在接到任务后，应该通过任务量，来评估他们是否承诺过度，如若发生，则团队应该在此基础上将任务再度分配，直至平均。
第11章 测量并监控速率
我们将项目分成一系列迭代来做开发计划，目的就是在各个迭代完成故事任务点时，可以明确当前开发速率，以判断接下来的任务及速度，可以重新安排计划。
计算速率时应该只考虑那些已经完成的故事，即通过验收测试的故事。不要计算迭代中团队尚未完成的故事。为每轮迭代计划和实际完成的故事点画图，可以更加有效直观的检测实际速率与计划速率的区别。速率趋势应当在多伦迭代后再进行预测，过早预测出的结果常不准确。累计故事点图和燃尽图十分重要，累计故事点图可以让我们了解每轮迭代中完成的故事点，而燃尽图，用于展示整体进度与剩余故事，，同时他还展示了每天剩余时间。这些图应该放在公共区域，以便整个项目组了解开发情况。
第12章 故事不是什么
故事是这本书讲解重点围绕的中心，也是整个开发项目中的核心所在，理解用户故事因此也就成为了必不可少的事情。为了更容易的理解用户故事，我们可以先弄懂它不是什么。
本章对三个需求方法进行了解释，他们分别是： IEEE 830（电气与电子工程师协会于1998年修订的“如何编写软件需求规格的指南”）、用例、交互故事场景。他们各有优缺点，首先，IEEE文档格式乏味、费时，并且需求常常不切合实际，不同的用户可能会理解到不同的结果；其次，用例是对系统之间以及一个或多个用户之间交互的一般性描述。它相对于故事而言，覆盖范围稍大，完整性不足，容易造成故事不明确，而寿命也是一个影响要素，用例是一个永久性的 “工件”。最后，场景是用户与计算交互的详细描述。它比用例场景更大更全面，与故事的区别在于范围与细节。
同时还要注意以下几点：不管开始预想多全面，我们都无法完全定义一个完整的具有相当规模的系统，考虑到用户的目标比例饿出方案的特性更为重要。
第13章用户故事的优势
从上一章我们得知，处理需求的方法多种多样，但是我们为什么要选择用户故事？因为它会带来多种好处：
①用户故事强调口头沟通：自古以来，口头表达是十分重要的。而且相比于书面书写的易产生歧义，口头表述更见简单明了，需求文档也是如此。
②人人都可以理解用户故事：相比于一些墨守成规的软件需求里的技术术语，用户故事使用的语言更容易使用户理解，简洁明了，同时更能增强用户对故事的记忆。
③用户故事的大小适合做计划：其他类型的需求分析关联性太强，并且还比较笼统，大小不能称得上是易实现的适合需求。
④用户故事适合于迭代开发：由于用户故事的特性，使得开发者可以根据当前需要，按照想要的进度实施开发。
⑤用户故事鼓励延迟细节：用户故事允许我们先设定一个目标层面的故事，之后实际开发的时候，再将其细节化，加快整个团队的进度。
⑥用户故事支持随机应变的开发：由于用户的不可控性，需求常常会变动。在以往从上到下的需求分析方法中，这简直就是噩梦，它会让我们前期定下的所有需求全部作废。用户故事则很好的解决了这一点。
⑦用户故事鼓励参与性设计：用户故事本身不像其他需求方法都是专业术语，用户可以完全理解，他们也就更愿意参与设计他们所需要的软件。在这个过程中，我们就能更好的了解用户的需求，做出更优质的分析。
⑧用户故事传播隐性知识：隐性知识指的是目标系统的既有属性，用户在工作时习以为常，认为我们应该知道，但是我们因为不熟悉流程无从知晓的知识。由于用户可以参与设计，这就有利于我们挖掘出用户的潜在需求，缩短我们的开发周期。
尽管如此，用户故事仍但会存在一些不足：在大型项目中，用户故事数量增长，导致其间的关系可能错综复杂，不易掌控（解决方案：增加用户，降低细节数量）；开发过程如果需要可追溯性，额外文档还是不可避免（每轮迭代产生故事文档，其中写入该轮迭代的工作，保持文档的更新）；不适合特大规模多团队的结构（还是需要进行相关的交流记录）。