有了团队交付能力值，便进行以下步骤安排本迭代的工作：

　　1）按照优先级顺序，列出story，并注明它们的故事点数大小。

　　2）判断一个迭代中可以交付多少故事点数。

　　3）考虑团队需要完成的非用户故事工作可能产生的影响，比如在早期的迭代中，由于工具和工作环境不到位，工作效率会受到影响。

　　4）向计划中加入一个新的迭代。

　　5）向迭代中加入故事，直到用掉所有的工作能力。

　　6）询问：是否所有的故事都已经解决、版本发布目标是否达成。

　　7）如果没有，那么向计划中加入新的迭代，并重复步骤5和步骤6.

　　8）一旦所有的故事都已经分配完成，与大家计划进行交流，并征求他们的反馈，看看这些计划是否现实并且可以完成。

　　PS：通常只会进行到第五步，剩余的stroy放入需求池，下个迭代启动时再规划。

　　（3）每日站会

　　站会的目的有三个：

　　（1）周知进度

　　仅从用户故事和任务的层面周知进度，任务进度只有两种状态：完成或未完成（完成百分比）。

　　（2）周知计划

　　你将会在下次会议之前做哪些工作？

　　（3）抛出问题

　　哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）如果遇到需要解决的问题，可以在每日立会之后处理。

　　实现一项目的必要前提：

　　1）站

　　2）敏捷项目必须提供能够“安全失败”的环境，团队成员不会因为没有达成任务承诺遭受惩罚。

　　大家要能够安全说出任务状态的真实情况，并且了解项目环境的现实情况。有时，我们的估算可能很糟糕（只是估算而已，又不是承诺），又或者某些事情的发生让某些成员无法完成任务，整体环境必须让他们能够说出真实情况，这样团队成员能调整他们的日程表，将任务排序，并调整适应项目的现实。

　　站会的主要内容：

　　从PM、RD到QA，每个人发言，内容为：1. 昨天干了什么，2.遇到什么问题，3.准备干什么。如果有想要分享给大家的知识，也可以在此分享。

　　后主持人总结一下，然后根据实际遇到的问题，少数人进行线下沟通、跟进、解决。

　　站会的时间尽量控制在十分钟左右。