Introduction 

In the Transition phase, most activities happen in parallel. The main objectives are to fine-tune functionality, performance, and overall quality of the beta product from the end of Construction phase.

The activities performed in a typical iteration during the Transition phase are described below.

Manage iteration

This activity is performed throughout the lifecycle. The goal of this activity is to identify risks and issues early enough that they can be mitigated, to establish the goals for the iteration, and to support the development team in reaching these goals.

Similar to other phases, this is an activity led by the project manager (in collaboration with the team) to launch the iteration, to allocate work, to track status, and to handle risks and issues. It’s unlikely that risks of high impact will happen during the Transition, but it is recommended that the project manager and team identify any potential issues while delivering the product to the end users.

If this is the last iteration of the project, the main goal is to achieve final acceptance of the system. At the end of the iteration, results are assessed against phase objectives, and stakeholders' concurrence on the project objectives is obtained. The team conducts a retrospective review to capture lessons learned and make improvements to the process for subsequent projects. The project is then closed.

Ongoing tasks

Submission of change requests during the Transition phase works differently than in other phases. New requirements will rarely be identified at late stages of the software development lifecycle in a way they can be implemented in the current release. If there are enhancement requests, though, they can be captured in the work items list and allocated to a future release, when a new software development lifecycle begins. In that case, requirements will be outlined and detailed accordingly.

However, defects are typically dealt with during the Transition phase, thus a stable release can be accepted by the user community. If there is general agreement from stakeholders, correction of low-priority defects can be postponed to subsequent evolutionary releases.

Develop solution for requirement within context

This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main goal of this activity is an executable system that provides the incremental quality and functionality for the specified requirements within the specified context.

During the Transition phase, most requirements will have been already implemented and validated, which is the focus of the previous phase. Nevertheless, there may be a few low-priority requirements that could be accommodated in the release being developed. However, enhancement requests and defects found in previous iterations may need to be allocated to developers.

Validate build

This activity is repeated throughout the lifecycle. The main goal of this activity is to validate the current increment of the system against the requirements allocated to it.

This activity happens in parallel with development of the solutions for enhancement requests and defects (and possibly remaining requirements), to make sure that a stable release can be presented to the user community. Users can be involved in performing tests to accept the release.