敏捷的核心是“拥抱变化“，那么我们为什么要做计划呢？
计划可以帮我们有序的推进目标，敏捷的计划频度相对于传统开发更加高频，敏捷计划更加灵活，我们称呼这个为迭代计划。
时间盒:时间盒是一个管理方法，即在预算的时间范围内对完不成的功能进行删减和延迟，而不是拖延预算的时间。一个好的迭代计划应该是在预算时间范围内尽可能安排价值最高的代办事项。
制定合理的迭代计划，我们需要考虑以下几点：
确定迭代周期：一般在1-4周，主要取决于两个因素:敏捷成熟度和自动化测程度
确定一个迭代周期的关键工作项，比如什么时间进行需求评审，什么时间测试。
里程碑事件的发生时间：比如我们两周进行一次迭代，然后在第二周的周一进行需求评审，周二开始测试。利用进度墙，将关键工作的时间放在团队能清晰看到的地方，大家共同遵守。
培养团队的工作节奏：根据上述的进度来安排每周固定的会议，比如需求评审会、迭代复盘会、迭代计划会等。
迭代计划会议
确定会议目的
确定会议参与人
会议议程
确定迭代目标
会议议程
1.what:明确要做什么，在这部分我们要换位思考，站在用户的角度，作为用户去使用产品，也就是我们说的讲故事。
MosCoW法则我们可以参考下：
Must：必须做的事情（没有他们系统将无法使用);
Should：应该做的事情(没有他们，系统将很难使用);
Could:可以做的事情（产品的附加值，加分项);
Would not:不要做的事情(没有意义)。
2.How:明确我们怎么做。
分解任务，遍历所有的用户故事，将其分解成团队成员可执行的任务，分成前端、后端、测试、运维等。
用户故事的分解遵循谁执行谁分解的原则。最后团队承诺。保质保量，尽量做到不延期的完成任务。
两种估算方法：
1.理想人数估算
名词解释：假设没有任何突发事件的理想情况下，一个开发人员开发该该故事需要的工作量。会造成一定的差异化。存在着估算的人和执行的人不是同一个人，会造成工作量的偏差偏大。
2.故事点数估算
建立共同认可的估算基准值。比如一个需求需要几个页面、对数据库的操作多少次，也可以是完成操作的步骤。这是需要预先定好的基准。
对同一个需求，每个成员给出自己的估算值，通过估算扑克方法同时呈现。
估算最低和最高成员说明自己估算的理由。
对同一需求进行2-3轮的估算，通常5分钟左右就可以确定最终该需求的估算。
重复2-3步，直到估算完成本次迭代所需要的工作量。但这种估算方法周期较长，一般估算会花费2个小时左右。
一般的经验证明，刚开始敏捷的团队，可以使用理想人数估算法。对于敏捷一年以上的团队，可以尝试使用故事点估算，这样团队比较容易达成一致。