敏捷交付的一个常见原则是“基于节奏开发，按需发布”。这意味着项目团队在每次迭代过程中继续保持将用户故事和主题转换为可工作软件的可持续速度，但是要根据需求交付给客户。发布计划，作为一项活动，是由产品负责人（Scrum）或现场客户（如XP）驱动的，大部分在项目开始时就完成了。结果是一个发布计划，它有助于设定在什么时间框架下用技术匹配实现什么。正如我们在前面的部分中所看到的，发布计划与整个产品路线图和组织的战略远景相吻合。由于发布也充当逻辑里程碑，发起人也可以为特定的发布分配预算。它可以被认为是以一定的价格购买了一套有价值的特性和功能。发布计划在项目的整个生命周期中经常更新，以使其跟上需求、优先级和团队速度的变化。

完成日期驱动发布计划 Date-driven release plan

发布必须在给定的日期前完成，但是版本中包含的特性的范围是可以协商的。固定日期可能来自项目承诺或监管约束

1. 团队从一个按优先级排序的故事待办事项列表开始，对它进行评估。在发布计划级别，使用亲和估算。
2. 团队确定估算的团队速度和迭代长度。
3. 基于发布日期，他们决定了在发布日期之前可以完成的迭代的数量。因此，如果发布是12周之后，而迭代长度是3周，那么只能交付12/3 = 4次迭代。
4. 团队最终通过将估算速度与迭代次数相乘，计算出在该发布版本中可以交付的故事的总估计值。例如，如果团队的预期速度是每个迭代中100个故事点，那么团队承诺在4个迭代中交付100 * 4 = 400个故事点。

5. 因此，团队将从合计不超过400个故事点的待办事项列表中选择优先级最高的故事。

   特征驱动发布计划 Functionality-driven release plan

   特性的集合是预先确定要交付的，但是团队会努力尽快交付它们。特性集由PO基于用户需求或市场条件来选择。以下是团队到达发布日期的步骤。

6. 团队从故事的优先级安排开始，并对它们进行评估。

7. 团队决定一个估计的速度（完成100个故事点）和迭代长度（3周）。
8. 团队汇总将包含在发布版本中的所有故事的估计总和。发布总共有600个故事点。
9. 将总估计值除以计划的速度，团队计算团队需要交付商定范围的迭代次数。在这种情况下，迭代次数将是600 / 100 = 6。
10. 每次迭代持续时间为3周，完成发布的总时间将为3 * 6 = 18周。注意，在这两种版本中，速度都是决定完成日期驱动发布计划的范围或特性驱动发布计划的日期的重要输入。正如我们在关于速度的部分中所看到的，团队在几个迭代中可以有不同的速度。所以他们应该考虑乐观的、悲观的，或者最有可能的速度来完善他们的发布计划。