第10章 迭代计划
制定出上一章的成果发布计划，我们可以顺利地将粗细度的故事分配到多伦迭代中。多伦迭代是发布计划的进一步激化，但只在迭代即将开始的时候才开始做迭代计划。为此，迭代计划会议必不可少，客户以及团队的所有人员都要参与其中。在这一过程，各个人员仔细讨论每个故事，从故事中分解出任务，开发人员承担每个任务的职责。这个会议是客户为团队调整故事的最佳时机，但是切记项目团队不要随意被客户打乱开发计划。
任务的大小没有强制的范围（例如：3小时到5小时）。相反，从故事中分解任务，用来帮助估算或鼓励多个开发人员合作完成一个故事。并且要保证每个任务都有开发人员承担，不要遗漏或者丢失任何一项任务。每个开发人员在接到任务后，应该通过任务量，来评估他们是否承诺过度，如若发生，则团队应该在此基础上将任务再度分配，直至平均。
第11章 测量并监控速率
我们将项目分成一系列迭代来做开发计划，目的就是在各个迭代完成故事任务点时，可以明确当前开发速率，以判断接下来的任务及速度，可以重新安排计划。
计算速率时应该只考虑那些已经完成的故事，即通过验收测试的故事。不要计算迭代中团队尚未完成的故事。为每轮迭代计划和实际完成的故事点画图，可以更加有效直观的检测实际速率与计划速率的区别。速率趋势应当在多伦迭代后再进行预测，过早预测出的结果常不准确。累计故事点图和燃尽图十分重要，累计故事点图可以让我们了解每轮迭代中完成的故事点，而燃尽图，用于展示整体进度与剩余故事，，同时他还展示了每天剩余时间。这些图应该放在公共区域，以便整个项目组了解开发情况。
第12章 故事不是什么
故事是这本书讲解重点围绕的中心，也是整个开发项目中的核心所在，理解用户故事因此也就成为了必不可少的事情。为了更容易的理解用户故事，我们可以先弄懂它不是什么。
本章对三个需求方法进行了解释，他们分别是： IEEE 830（电气与电子工程师协会于1998年修订的“如何编写软件需求规格的指南”）、用例、交互故事场景。他们各有优缺点，首先，IEEE文档格式乏味、费时，并且需求常常不切合实际，不同的用户可能会理解到不同的结果；其次，用例是对系统之间以及一个或多个用户之间交互的一般性描述。它相对于故事而言，覆盖范围稍大，完整性不足，容易造成故事不明确，而寿命也是一个影响要素，用例是一个永久性的 “工件”。最后，场景是用户与计算交互的详细描述。它比用例场景更大更全面，与故事的区别在于范围与细节。
同时还要注意以下几点：不管开始预想多全面，我们都无法完全定义一个完整的具有相当规模的系统，考虑到用户的目标比例饿出方案的特性更为重要。