在敏捷方法中，加载一个团队工作是通过迭代规划完成的。由于迭代的急促性（通常是一到六个星期）一次计划的重要性收益减少而做计划的重要性收益增加。对于小项目来说，在一个时间段内只计划一个单次迭代可能是很充分的。迭代计划应用到运行多个迭代或多个团队项目经历的缺点是迭代活动的长期影响的视角可能会被忽略。换句话说：“宏观” 视角的都将丢失。一个解决办法是增加规划的层次来整合“宏观上”的视角。在计划驱动和瀑布方法中，这个问题通过前期大量的设计被克服了，旨在准确预测每个项目的任务工作量是多少。这会导致在项目前期投入大量的资金，而所设计出来的产品功能不确定是否符合产品负责人的预期。一个具有多层次规划的解决方案将会避免重复前面大量的设计工作。
大规模研发工作的计划活动应该依赖五个层次：
-
产品愿景
-
产品路线图
-
发布计划
-
Sprint计划
-
每日承诺
在五个层次的每个层次中开展活动的确定性增加，因此，大量的细节（投资的钱）、涉及的人数、频率会增加，并且没有将资金浪费在未开发或以不同方式开发的功能上的风险。
五个层次规划的基本规划原则：优先级，估算和承诺。
产品愿景——第一层次
愿景就是产品负责人对产品未来最广阔图景的描述。在这个愿景中，她解释了一个组织或产品应该如何呈现。她会指出哪部分系统需要改变（优先级）以及应该付出哪些努力来达到目标（估算和承诺）。
产品愿景——如何做
一个远景规划工作的可能结构是创建一个电梯声明或一个产品愿景盒。这两项工作的原则是创建语句来描述将来期望产品的特征、目标客户以及与以前的产品或者有竞争力产品的关键差分点。
杰弗里•穆尔在他的电梯声明中使用下列结构：“对于 (目标客户)来讲， 谁 (阐述需求) (产品名称) 是一个 (产品目录) 以及 (产品关键收益, 购买原因). 不像 (一般的竞争对手的主流产品), 我们的产品 (对主要区别作最后的陈述).”产品愿景描述产品在将来12个月或以上的状态。进一步的规划（设计）活动将细化愿景，并可能从最初的愿景上转移，因为未来将使我们改变看待市场、产品以及为将愿景变成现实所付出的努力的角度。
产品路线图——第二层次
大型项目几年后交付的时代已经离我们远去。客户要求会更频繁地变化，典型的产品上市的时间表只需要数周以至数月。更高的频率和更小的时间表迫使产品负责人不得不思考一步步通往最终产品的路线。就像把前期计划好的旅途路线与同路人分享、沟通一样。创建产品路线图，并与交付团队沟通，这样做的目标是为了让产品负责人能够：
-
整体沟通；
-
当需要发布时进行确定和沟通；
-
决定哪样功能对每次发布是充分必要的；
-
专注于来自发布的商业价值；
另一方面交付团队将：
-
全盘检视；
-
了解实现愿景的步骤；
-
学习业务优先级；
-
提供技术输入的路线图；
-
提供对项目特征的预估；
产品路线图——如何做
创建的产品路线图，主要是由产品负责人（或产品负责团队）驱动。这个阶段的项目对技术限制的影响有限。在一次会议或一系列的会议上，产品负责人将绘制产品路线图。可以毫不夸张地说，通过发布的图形显示，或以更正式的书面文件列出日期、内容和可预见发布的目标。
产品代办事项列表
预测下一个计划阶段（发布计划），需要建立预期的特征列表——产品待办事项列表。在最简单的表格中，这样一个待办事项列表是一个介绍产品要求的电子表格，简洁的描述可以使得交付团队提供实现每个特征的预期。最重要的是，这个列表要有优先级。敏捷项目的成功取决于早期交付最高优先级的特征。因为一个项目的成功是从商业的角度来衡量的，功能列表的优先排序是负责商业的人决定的，即产品负责人。产品负责人与交付团队的交互是必需的。没有对特性/功能的讨论，交付团队就很难对可接受的不确定性进行估算。一个产品待办事项列表的特征应包括：
-
所有团队只有一个产品待办事项列表（看到整体）；
-
大至非常大的功能（由20人工作20天来交付一个功能）；
-
功能优先级基于业务优先级（通过市场调研发现）；
-
技术功能（有时被称作非功能特性，以工作期望的方式来做产品，例如：为了保证一定的系统性能来实现一个特定的数据库管理系统）被那些对产品在市场上的成功有直接影响的特征所限制。
发布计划——第三层次
在小的项目中（单个团队在几个迭代后交付产品增量），单单一个产品待办事项列表就能够提供足够的项目概况。规模、可持续时间、可交付成果很容易识别， 没有必要同步交付或集体交付或团队交付。当把敏捷的概念应用于项目中时，团队和项目之间将会有一种依赖的关系时这将要改变。一些团队可以根据不同的敏捷原则运作，或在一个瀑布式流程中运作。在计划发布的第一刻就开始分组活动并将他们分配到各个小组当中。
发布，顾名思义就是，一组产品增量发布给（内部）客户。
发布的一些特征有：
-
发布由日期、主题和计划的功能群定义。发布日期可以链接到事件，如会议或法律体系的变化；
-
范围，不像日期或是质量，它具有可变性。它凸显了使用优先级产品待办事项列表作为一个计划事件的基础的必要性；当一个发布日期不能改变，增加预算是不可能的情况下，通常对发布本身是没有积极影响的，范围就是唯一可改变或打破发布日期的变量；
-
所有的团队必须保持相同节奏的迭代，当所有团队以相同的节奏工作，相互依赖的探索和管理活动就会自动在规划中出现；
-
有固定的发布日期贯穿于项目中的所有团队：2到4个月是典型的时间间隔；
发布计划——如何做
有了产品愿景和产品路线图，并且产品负责人以及团队能够定期更新审查，每个人都对下一个版本的重点、主题以及发布的日期了如指掌。此外，产品的功能均体现在产品待办事项列表里，并已经过估算排出优先级。通过这些练习，产品负责人和交付团队对必须交付什么、何时以及为什么达成一致的理解。
一个典型的发布计划会议通常需要一整天的时间，有时候需要2天的时间，如果项目非常大的话（100多人的团队）。所有的团队成员参加这个会议：包括产品负责人、交付团队和干系人。这个会议是高度协作和互动的；使用的工具通常是便签纸、活页挂图以及白板。一个日常工作事项应该是：
-
介绍、目标、日程更新
-
产品负责人解释产品愿景和产品隐喻
-
版本发布和迭代的时间盒
-
之前版本的影响和迭代
-
交付团队生产力的计算
-
可交付功能协议（即什么时候能“完成”一个功能）
-
在个人团队分组座谈会议上将功能发布。这可能是一个文字性的“移动”，当把功能写在便签纸上，靠单独的翻页来代表功能发布。团队里的所有成员都加入这项练习
-
在发布的过程中，由个人团队将功能由发布移至迭代
-
通过检查个人规划的结果来决定相互依赖关系，将功能移至需要的迭代或版本来解决此种依赖
-
最终计算出每次迭代的工作量以及与可用能力的比较
-
审查发现的风险和问题
-
所有参与者发布计划的承诺
-
回顾会议
迭代计划——第四层次
在发布计划期间确定交付功能，考虑功能之间以及团队之间的依赖关系。由于缺乏细节（直到可能的交付功能确定下来才会对设计活动投资），估算就会较为粗略，而且有一个可接受范围内的不确定性。版本发布内的迭代，会召开计划会议。在会议举行之前或是会议期间，具体细节会被通过任务分解加入功能。细节的添加可以提高估算的准确性。各个团队的实际工作容量比发布计划会议更有把握。这些增加的精确性的结合使得团队能够在迭代期间承诺实际交付的一些功能更具高度的确定性，实际交付。
迭代计划——如何做
迭代计划会议的结构类似于发布计划会议。尽管团队的独立工作产出他们的迭代计划，但是团队之间的同步将会提供一个有效的机制来检测和解决依赖关系。计划会议的日程，与发布计划会议的有很大相似之处，与愿景规划的主要区别是：在所有活动中只发现一个迭代。在团队—团队的基础上进行的核心活动：
-
各团队确定自己的实际能力，或迭代内能完成的工作量。
-
各团队分解许多似乎可以在下个迭代中完成的任务——这个可以在准备工作中完成。
-
估算每一项任务，一个典型的任务大概是半天到两天的时间。
-
当分解和估算功能的时候必须考虑完成的定义：直到一个功能被充分地测试并被产品负责人接受，这项功能才算完成。
在发布计划会议上不会看到像在联合会议上各团队的结果被检查来决定依赖关系（或这种依赖关系消失）。
日计划——第五层次
许多敏捷团队习惯召开每日例会——即Scrum站会。在一个15分钟的会议上，团队内每位成员更新他们的状态（“我昨天做了什么”），承诺今天的工作（“我今天将要做什么”）以及报告困难（“我遇到了什么困难”）。这个每日例会通常不会被看作计划会议，但它肯定是计划会议。人们的目光提前一天向前看，从早期迭代中学习，并且互相告诉对方他们打算做什么。被提出的问题可能被解决，在迭代中成功交付期望功能，可以在会后决定。
站会——如何做
像其他计划活动一样，团队之间需要同步每日计划。这在协调的站会上发生（Scrum方法论中的Scrum of Scrums会议）。每个团队的代表以相同的模板彼此互相报告团队的状态、计划和遇到的阻碍。这三个问题的回答跟在站会上的回答一样（“团队昨天完成了什么”，“团队今天将要做什么”，“什么阻碍了团队的进展”）。什么是可见的？
-
所有团队进展如何？
-
贯穿团队的阻碍是什么？
-
谁正在采取行动移除障碍？
一个协调站会的原则可以重复处理大量的团队：“团队的团队”的代表报告“团队的团队”的工作进展。这些会议通常会协调没有共同背景的团队的努力。例如，所有的IT交付团队有一个协调（每日）站会，培训团队、财务团队、制作团队等等都是如此。在每周（或发布周期后期）的每日安排上，团队的代表开会报告进展、计划和障碍。
结论 本节讨论了交付团队的工作，通过在正确的时间用正确的层次细节来交付活动计划。通过分期活动计划，在长期和约定的以及前期的设计、计划投资之间找到一个平衡点。通过交付团队对发布和迭代的所有权计划，团队和个人负担过重的风险将会大大降低。
