第8章 估算用户故事
使用故事点 我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必保证每次迭代的故事点的度量是一致的。 如果用结对编程呢？ 团队用不用结对编程，对故事点估算并没有影响。团队可以采用理想结对日或理想个人日来估算故事点，区别会表现在速率值上。 一些提醒 一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等。 类似地，一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。 开发人员职责 1.负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。 2.负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。 3.负责以团队估算。 4.负责估算应与其他估算一致。即所有2点的故事都应该差不多。 客户职责 负责参加估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。
第9章 发布计划
在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级。 故事应该以明确的顺序排列（第一个、第二个、第三个，等等），而不是利用诸如“非常高、高、中等”模糊顺序的分组。 故事的优先级由客户确定，但也要考虑开发人员的想法。 使用速率将以理想日为单位的估算转换成日历日。 估算团队的初始速度是很有必要的。 开发人员职责 负责提供信息（有时包括基本假设和可能的替代方法）给客户，以帮助她排列故事优先级。 负责在基础性需求或者架构性需求与其他客户端需求之间取得权衡，避免不切实际地提高基础性需求或架构性需求的优先级。 建立发布计划时，负责在实际故事点基础上，适当包括一定长短的时间用以项目缓冲。 客户职责 负责以自己对故事价值的估计来确切排列用户故事的优先级。把故事排列为高、中、低这三个优先级是不够的。 负责诚实地表达发布期限。 负责理解理想日和日历日的不同。 在想对故事的不同组件排列不同的优先级时，份额则分割故事。 负责理解为何不应该谴责或批评一位个人速率为0.6的程序员，只因为她的速率小于1.0。
第10章 迭代计划
迭代计划是发布计划的进一步计划，但只有在迭代即将开始时才开始做迭代计划。 开发人员职责 负责参加迭代计划会议。 负责帮助把所有故事划分为任务，而不只是自己想做的故事。 负责为认领的任务承担责任。 负责确保承担适当工作量的工作。 在整轮迭代中，负责监控自己剩余的工作，同时也要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。 客户职责 负责参加迭代计划会议。 负责对迭代中包含的故事排列优先级。 负责指导开发人员交付他们能提供的最大商业价值。这意味着，从发布计划设定之后，荣有更高价值的故事，要负责调整优先级以交付最大的商业价值。
第11章 测量并监控数据
完成一个任务或故事所花费的实际小时数对当次的速率没有影响。 每日燃尽图在迭代中十分有用，它展示了迭代中每天剩余的小时数。 设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。 开发人员职责 尽量在完成一个故事后再去做下一个故事。我们更希望看到少量已完成的故事，而不是较多未完成的故事。 经理或者极限编程项目中的追踪者，应知道怎样以及在什么时候画本章中的这些图。 客户职责 知道团队的速率 知道实际速率和计划速率的差别和是否需要调整计划。 为发布添加或删除故事，以确保团队在种种限制条件下尽量多实现项目目标.