第八章 估算用户故事
故事点有一个很好的特性是团队可以定义自己认为合适的故事点，一个团队可能定义一个故事点为一个理想日的工作，也可能定义为一个理想周的工作。故事点有很多意义，所以故事点代表时间的模糊单位。
故事估算应该由整个团队集体来完成。故事估算属于团队集体有两个原因，第一个，还不确定团队中谁负责完成这个故事，第二个，团队决定的估算可能比个人估算更有用。
在估算时，作者介绍了他所用的方法迭代的方式进行估算。在初步估算好后，成员进行讨论，然后进行下一轮的讨论，最终达成一致。
三角测量。估算一个故事时根据这个故事与其他一个或多个故事的关系来估算。假定一个故事估算为4个故事点，第二个故事为2个故事点，程序员应该都同意，第一个是第二个时间的两倍。
使用故事点，在一轮迭代结束时，团队计算已完成的故事点数。因为下一个迭代也是同样的长度，当前的故事点可以作为预报。如果预算每个星期完成30个故事点，实际完成了50个，那么他们可能实际所用时间比预定时间会少。
第九章 发布计划
我们什么时候发布，在理想的情况下开发人员和客户可以谈一个日期范围。团队做发布计划时，能以一个可接受的日期范围为起点，那么他们的发布时间将更灵活。
为了计划一个发布，客户必须排列故事的优先级，我们可以借用DSDM的方法。分为四种：必须有的，应该有的，可以有的，这次不会有
我们可以通过多维来为故事排列优先级，此外客户和用户排列优先级时，也会有他们自己的要素。总的来说，开发人员实现故事时会有一个顺序，就像客户所希望的那样当客户和开发人员对这个顺序有不同意见时，最后每次都应该是客户说了算。
当一个故事的优先级遇到问题时，可能要分割这个故事，使它的独立的故事有不同的优先级。
在软件开发的早期，大家一直争论是先做有最风险的部分，还是先做有最价值的部分。敏捷开发支持先做最有价值的部分，但是排列故事优先级时要考虑风险。
根据架构需要安排优先级。高风险的故事经常与基础性或非功能性需求有关。有时用户将架构的要求放在低优先级，但是如果更改，会使整个程序变动。这时程序员可以提用户写一个高优先级的故事写明架构。
开发人员和客户共同选择适合他们的迭代长度。长度为1到4周。一般为固定长度，如果有需要可以适当更改一次。