迭代计划的方法有速度驱动的和承诺驱动的，速度驱动的迭代计划步骤如下：
首先可以调整优先级和确定目标速度（同最近一次的迭代速度）；然后确定迭代目标，即此次计划实现的工作概括说明，然后按优先级选择高优先级，可以支撑目标实现的故事，然后把故事分解为任务，对每项任务进行估计。具体实施步骤如下：
1.调整优先级，优先级调整的来源可以是迭代评审会议，也可能是市场或商业环境发生变化引起的，或者根据优先级的四象限（风险、价值）决定的，如果可能，尽可能将迭代评审会议和接下来的迭代计划会议放在同一天进行。
2.可以使用最近一次的迭代速度来确定目标速度
3.迭代目标是此次迭代目标的整体概括性描述，不需要太明确。
4.在迭代目标确定后，需将与迭代目标相关的所有故事整理出来，按照优先级和迭代速度的要求，选择用户故事。
5.故事分解为任务是，需要将用户故事所需要进行的所有任务都鉴别出来，如：分析、设计、用户交互设计、测试和编写文档，均属于任务的具体内容，因为迭代的目标是产生潜在可交付的产品，因此标准是要按照交付可用的产品功能来分解任务。具体包含如下任务：
1)只包含为此项目增值的任务,如分析、设计、编码、测试、用户界面设计等，而邮件处理，绩效沟通等并不属于此项目增值任务
2)将一些任务明确出来，直至形成习惯，如：编码的同时需要编写单元测试或自动化测试用例，需将此工作明确，直至养成习惯后才可以包含在编码工作中。这样编码工作的估算就默认包含了单元测试。
3)会议时间，项目的会议是将需要作为一个任务输入到迭代计划里，作为一个单独任务。
4)缺陷尽量在当前迭代版本里进行修复，如果放到下一迭代计划成为缺陷或者功能区别不大，只是不同称呼而已。
5)任务间的依赖性，对于自然顺序的工作，需要考虑如果按照自然顺序可能会导致开发周期拉长，如果不能按照特定的自然顺序，则需要考虑这种顺序需要提前准备哪些工作，将这些任务输入到迭代计划里，如新建一个数据，然后删除，如果不做这样的操作，直接删除，则需要在系统里存储一条数据，以支持删除动作。
6)对于难以分解的任务，可以分解为评估这项工作的影响（也就是探针spike,探针是用来回答问题或者获取知识的工具，在团队难以推测某件事时，就通过使用探针的方式来评估），完成这项任务的时间（占位符）两个任务构成，即一个探针和一个占位符（用来评估持续时间）来代替此项任务。
6.任务估算，可以确定一个任务估算一个，也可以将任务分解为每个任务后一起估算。首先，估算是一个团体工作，任务分解后并没有确定完成此项工作的人员；其次及时确定某人，也不代表其他人没有贡献，第三，听到预期的时间后，觉得时间不在预计之内，可通过沟通及时帮助团队发现误解；最后，如果由负责工作的人做出估算，可能由于自尊心或者其他原因不会承认自己估算的不准确。如果是共同估算的，就不存在承认错误的情况。
在估算的时候，一方面，进行一些设计有时候是必须的，否则可能完全不知道如何开展工作，自然无法建立任务列表，迭代不需要绘制一个设计图，只要能够支持对完成功能所需要的工作进行推测即可。另一方面，任务需要适当的大小，大致是每天完成一项，这样方便大家大多数的时候每天至少能够汇报完成了一项工作，对于大于这个大小的任务，可以看作占位符，到充分了解后，再做调整。
