迭代计划通常是通过对计划进行更改来适应项目进行的过程。仅仅由于基于监视过程的反馈，对项目假设，风险的一些更改以及范围，预算或进度的更改，就可以更改计划。在计划过程中包括团队是非常重要的。基本上，计划通常与解释和定义以及中间结果的实际顺序有关。在此事件中，每个团队成员都确定有多少团队积压，他们可以承诺在即将到来的迭代中交付。
迭代计划通常是仅讨论和计划开发过程中的软件应用程序的下一个周期，阶段或迭代的过程。渐进式的已制定计划非常重要，因为作为早期的推测，总会在已开发的内容和进度表中进行调整，只是会逐渐演变为高度理解的项目环境。
- 初始迭代：
在某些情况下，项目包括新产品的推出或仅是新技术的创建，迭代对于进一步解释项目范围，风险和所有收益可能是必不可少的。它还可能涉及用例模型，业务用例，风险列表，体系结构概念证明甚至项目和迭代计划的质量的进一步提高。在某些风险和所需投资都很高的情况下，也可以建议延长启动阶段。也可以建议问题域是新的或团队经验不足的地方。早期的原型技术还集成了候选人体系结构的基础组件，还提供了一个可执行的框架，用于解释和简单阐述系统的用例。为了实现可接受的原型，大规模和定制开发是两个迭代。但是，对于多个项目来说，仅使用一个项目就更好了。初始迭代通常负责建立范围和远景，并解释和定义业务案例。
- 细化迭代：
在每次迭代中，支持环境都会进一步完善。如果最初的阐述只专注于准备分析，设计和实现的环境，则第二次迭代可能专注于准备测试环境。测试环境的准备基本上包括配置测试过程，编写开发案例部分，以及准备或生成测试和设置测试工具需要遵循的模板和指南。精心设计的迭代还可以使体系结构具有完整的执行框架和基础结构。为了达到可接受的体系结构基准，某些项目需要两次迭代。空前的体系结构可能需要一些额外的迭代。另一方面，可以通过单次迭代来获得在高度完善的体系结构框架上开发的项目。在细化迭代过程中，完全定义了需求，并建立了完善的体系结构。
- 施工迭代：
施工阶段后期迭代的基本结果是增加了更多功能，从而使完整的系统越来越多。在构造迭代期间，通常会实现用例，并且充实了体系结构。一些项目需要并且需要两次施工迭代。首先是一个alpha发行版，其中包含针对每个关键用例的可执行功能。第二个是beta版本，该版本提供了95％的总产品功能范围，并且还实现了一些必需和重要的基本质量属性。 - 过渡迭代：
过渡迭代通常负责将产品迁移到用户社区。一些项目仅使用一次迭代即可将Beta版本转换为最终产品或最终产品。即使是这些项目，也只能学会在Beta版本与最终产品或最终产品版本之间进行一次迭代。