此工作产品的目的是：

• 在团队层面，通过交付工作、经测试的软件来关闭系列sprint/迭代，这些交付工作和软件可能被最终用户社区所使用。
• 在程序层面，向客户交付一个集成的、增值的产品增量，此增量是由多个、协调的以及同步的开发团队成员平行开发的。

发布包含集成的、编译的代码，它可以干净的、独立的、作为一个整体运行。这是一个重要的规则，因为为了发布或者甚至“潜在可运行”，发布增量必须能够独立，否则它无法可交付运行。发布能够在流程程序或团队层面创建。

对一个发布来说有以下三种可能的使用：

• 未程序之外使用：以最小化风险及技术和程序功能来集成组件并进行构建。此种情况通常发生在新产品生命周期开始时。
• 由Beta客户和程序经理使用：运行最终用户在Beta测试环境中对它进行测试，这提供了直接的反馈并减低了和用户接口人机工程学方面的风险。客户反馈将影响后续对程序订单的考虑
• 被部署或潜在交付，并由最终用户使用：此结果为最终用户提供了直接的价值。

在许多组织中，一个程序发布的时间盒通常有2到3个月的开发工作，以及2到4周的固定时间，这导致一个预定的发布接近90天。针对个人开发团队的发布常常比针对程序的发布更频繁，但是并没有对发布安排的硬性时间要求。唯一的要求是通过开发团队和程序“频繁”的交付可工作的软件。尽管前面描述的时间窗有些武断，但经验证据表明它适合于大部分的公司，并很好的符合了季度计划周期。

每个发布都有一系列发布目标和一个项目交付日期；还包括一个计划的sprint/迭代数量。例如，发布的概要描述可能象“发布2的目标是为订单和物流部门提供B2B计划功能。此发布的目标时间点是6月31日，包含5个2周的特性开发Sprint/迭代，和一个2周的发布sprint/迭代。”