敏捷开发方法的阶段划分与传统的瀑布型生命周期是不一样的。敏捷展现出来的是一个又一个迭代，似乎难以展现项目的整体情况。与领导沟通汇报时难以在短时间内说清楚。
首先，识别项目的整体工期限制。 项目的整体限制主要在工期、工作量、成本。 一般常见的限制是项目最终结束日期。比如有些项目是获得了政府资助，那么政府对这些项目在何时结束是有要求的；有些项目是按年度计划的，要在12月结束；有些项目是根据客户合同来的，那么根据客户的时间要求来进行。 也有部分少数项目确实没有明确的工期限制，或者难以估计何时能够完工，这种情况下常见的做法是分期进行，把相对明晰的、优先级高的内容放在第一期中，把未知的、可变的部分放到后面的第二期或第三期。
其次，确定迭代周期 迭代周期是指迭代历时多少时间。常见的迭代周期是2周~4周，也存在1周的迭代周期，一般而言最长的迭代周期是8周，约2个月。 短迭代是敏捷开发方法区别于传统开发方法的最大特征。
迭代的英文原文是Iterative，这个词是舶来词汇，它的英文注释：Iterative是英文Iterate的形容词形式。看一下韦氏大辞典中Iterate一词的定义。 Iterate: To say or do again or againand again （重复地说或者做）。 很显然我们的迭代开发(Iterative)中的迭代取的是它的“不断地做(Doagain and again)”的意思。因此迭代开发背后的思想是一种与传统思维模式截然不同的方式，传统思维方式往往希望一遍做好，一次成功；但是迭代开发意味着反复地 做，不断地根据客户和市场的反馈进行调整。 敏捷开发的首要意图是尽快的将有价值的功能交付到用户手中，识别最高价值的可行的最小功能集，最快速的部署。来自于真实用户的反馈是最佳的标准。这些功能使用的反馈将指导后续的开发，特别是前期需求有误的，通过反馈修正后的功能将更有价值。 所有敏捷中的反馈很重要。敏捷开发的速度需要匹配于项目获得可靠信息的速度，也就是说反馈循环的紧密程度。团队的生产力也受限于所收到反馈的质量。反馈循环的紧密程度就与迭代周期长短紧密相关。短迭代带来了快速的反馈，能够快速的发现问题，尽早的进行调整。所以敏捷开发方法对迭代的时间长度有限制。
常见问题：迭代周期是否根据每个迭代的情况来调整迭代周期时间长短？ 尽量按照固定的迭代周期，把迭代作为一个时间箱来进行。在长跑运动中，保持不变的节奏是最省力气的，同样的，团队按照固定的迭代节奏开展工作，能够让内部外部各方有明确的预期。 对于时间箱而言，如果时间节点到达时尚未开发完所有功能，可以把没有完成的功能在下一个迭代继续开发。 但是如果有外部事件的重要时间节点，可以适当调整时间窗使得某个迭代结束时与外部项目吻合。 当总工期长度和迭代周期确定后，再考虑项目起始和收尾的情况，就可以把全部迭代计划做出。对于项目起始，常见的做法是安排第0迭代，第0迭代一般的时间长度不超过普通迭代的时间长度，主要的任务在于组织团队、建立开发环境及其他一些初始化的工作。 对于项目收尾，根据具体各个组织的要求来安排，诸如考虑进行外部测试、书写项目结题材料、对外宣传材料，等等。 然后，在选择合适中间点进行beta交付。 将得到初步识别的各个核心功能或特性安排到计划的迭代中。
以上规划中，识别的规模尽量不要超过开发能力的50%，因为敏捷开发不要求开始就有详尽需求分析，不少新的需求会在每个迭代的交流中出现。 根据需要开发的核心功能或特性，组合合适的迭代，安排beta交付或release交付。 常见的，每三个迭代安排一个beta交付；也有每个迭代都进行beta交付的做法；不少互联网的做法是每个迭代都进行release交付。
在迭代开展后，在向领导汇报时，可以这样简短的汇报：本项目总共规划了12个迭代，每个迭代周期是4周，当前进行到第5个迭代，前4个迭代原规划的 功能基本都实现了，除了……，并且新增加了什么什么重要功能。前4个迭代结束后，我们将满足beta发布的版本交付给了某个用户试用，目前收到8条反馈， 正在处理当中。 另外，迭代总体燃尽图也是一个展现项目整体的好工具。 如下是一个项目的功能点迭代燃尽图实例，纵轴是待实现的功能点数，横轴是迭代数。
通过这个图，已经进行了29个迭代，预示还需要6个迭代，可以把所有功能点数“燃尽”。
通过这个图上已经进行了29个迭代，预示还需要8个迭代，这就与功能点迭代燃尽图的预测不一致，项目组可以从中分析原因，采取措施，保证最后的工期。 上述图最直观的原因是剩下未完成功能比较难做，而前期已经完成功能可能需要修补。在这种情况下，有必要适当的在第28以后的迭代中加大工作负荷。
综上，对比下瀑布开发和敏捷开发，如果同样是工期为一年的项目，在瀑布开发下，可以作出开发计划、需求、设计、编码、测试等等阶段里程碑的安排，每 个阶段的平均工期约是2个月，而且就算是在编码刚开始的时候，也无法直观的看到需要的软件是什么样子，只能查阅大量篇幅的文档。
而在敏捷开发下，假设一年安排了11个迭代，每个迭代为期1个月左右，把已经识别的关键功能分配到各个迭代当中，每个季度交付一个beta版本，从计划颗粒度上讲就比瀑布开发来得更细， 从执行中的跟踪来讲，可运行的半成品软件较之经过里程碑评审的文档而言更加直观，更加说明已经获得的成果。 因此，敏捷项目整体规划是可以作的，而且其颗粒度并不比传统生命周期更粗。
