Each Iteration Results in a “Release”

To ensure that the project is making progress, each iteration is forced to produce something tangible: a “release.” This release can be:

  • A prototype that is used to demonstrate some specific capability
  • An “internal” release that is used to elicit feedback and that serves as the basis for further development and testing
  • An “external” release that is shipped to customers in some form

The following is our definition of release:

Release: A stable and executable version of a system.

The production of something executable during each and every iteration is so important to the iterative approach that some people even go as far as to assert that “The goal of an iteration is an iteration release: a stable, integrated and tested, partially complete system.”

In every iteration, all the software developed by all the teams involved in the project is integrated into a release. This series of releases provides the project with regular technical visibility points where the state of the project as a whole can be considered.

The idea that each iteration produces a release can seem confusing if you think of a release as something that is delivered to people outside the project team. When we use the term “release” we mean something that can be executed and evaluated, including things that are only evaluated internally such as prototypes, as well as external product releases. The early releases are incomplete versions of the system that demonstrate particularly important characteristics required of the system and address the major technical risks facing the project. As the project progresses, functionality is added incrementally
to the software produced by the earlier iterations until sufficient functionality is available
to enable the system to deliver real business value. After this point, subsequent releases can continue to be developed that implement additional capabilities.

An iteration’s release becomes a product release when you decide to release it to an operational environment for unconstrained use by the user community. Many of the releases produced will have the level of quality and completeness required by a product release, but not all will be worthy of release. For example, the release might contain insufficient functionality to be useful to the users, or the users might not be ready to receive the release. Each consecutive release should be marked by:

  • A growth of functionality, as measured by the implementation of additional functionality during the iteration
  • Higher quality, as measured by a reduction in the number of product defects
  • Reduced risk, as indicated by estimate fidelity, risk magnitude, and stakeholder confidence

When planning an iterative project it is important to understand the purpose of, type of, and audience for the release to be produced by each iteration.