迭代故事
整个团队通过举行迭代计划会议来为下一轮迭代做出计划，客户与团队中的所有人员全部参与。由于团队将仔细研究用户故事，所以毫无疑问他们会有一些问题。需要客户团队随时回答问题。
迭代计划会议的一般内容如下：
1.讨论故事
2.从故事分解任务
3.开发人员承担个任务的职责
4.讨论所有的故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会过于乐观的承诺。
讨论故事：
团队获得一个已经安排好的优先级故事集合，一次作为迭代计划会议输入。正如程序员可能改变他们对实现一个故事难度的看法，客户一样可能会改变他们故事优先级的想法。迭代会议会是调整故事优先级的良好时机。
会议开始时，客户从最高优先级故事开始，读给开发者听，然后开发者充分提问，知道他们理解故事，可以从故事中分解出任务。没有必要理解故事所有细节，过分的讨论每个故事的细节会导致会议变得冗长，低效，因为会议中不会每个人都需要聆听故事的细节。在计划会议后，开发者仍然有时间有客户一起交流。
分解任务：
将故事分解为任务没有什么窍门，许多开发人员他们的职业生涯一直在做这样的事情。由于故事已经比较小了，所以通常没有必要进行更多分解。
事实上，为何要做故事分解呢？为何不直接把故事作为独立的工作单位呢？
尽管故事的确可以小到可以作为工作单位，但是将他们分解出更小的任务，更符合项目的需要。首先对于很多团肚来说实现故事的开发人员不止一位。需要由多个开发者完成故事。
其次故事是对用户或者客户有价值的功能描述，他们并不是开发人员的待办事项 to-do list 。把故事分解成为人物很有必要。因为有助发现那些可能被人遗忘的任务。因为整个小组一起来划分任务，依靠的是所有人的集体智慧，尽管某个开发人员可能会忘记"有必要更新安装程序"是故事的一部分，但是所有人都忘记却不太可能。
敏捷过程为人诟病的地方之一，它没有像瀑布流那些前期设计步骤，这是事实，敏捷没有前期设计阶段，敏捷过程的特点是频繁的短期设计。当脑海里至少有一个最小的方案时，才可能从故事中分解出任务。所以一个故事的任务分解其实是即时设计（just in time design）中的一次短脉冲，这些短脉冲的集合取代了瀑布流的前期设计过程。
（此处书中有详细举例）
承担责任：
一旦确定了故事的所有任务，就需要有团队成员自愿执行每个任务。如果任务写在白板上，开发人员的名称写在他们认领的任务后边。
就算要采用结对编程，每个任务通常也最好只关联一个人的名称。此人将承担任务的责任。
实际上，确保完成任务是团队中每个人的责任。团队要有一种“同舟共济”的心态。而且，在迭代快要结束时，如果有开发人员不能完成自己接受的任务，团队中其他成员应该勇于承担。
虽然任务是每个人认领并承担责任，但是在迭代期间并不是一成不变的，在开发取得进展中我们对任务会更加了解，因此任务的认领与承若也需要做出调整。
估算并确认
假如一个项目团队的速率是每轮40个故事点，那么不断重复前面的步骤-讨论故事，分解任务，直到团队讨论客户提供的前40个故事点的故事。这时每个开发人员负责估算自己的工作量。最好的方法仍然是以理想时间估算。
此时任务应该足够小，以便做出可靠的估算。即使不行，也不必担心。预测一下任务完成需要的时间，然后继续前进。如果像本章早先推荐的那样，任务以及承担任务的开发人员的名字写在白板上，每个开发人员就可以在白板上加上他的估算。
一旦开发人员估算好自己的任务，就需要把这些估算加起来，进而做出实际的评估，看看是否在迭代中能否完成所有任务。
假设，为期2周的迭代开始了，我已经承担了一个任务，我估算完成任务实际需要53个小时，如果我没有把握在这些任务上投入这么多时间。这种情况下我可以选择：
1.留着所有任务，希望一切顺利。
2.请求团队其他成员接手。
3.与客户沟通， 放弃故事或者分割故事。
每个开发人员必须能够放心地承若完成自己将要承担的工作，而且整个团队必须同舟共济，所以每个人都必须对整个团队做出承诺的把我。