Introduction
In Transition, most activities happen in parallel. The main objectives are to fine-tune functionality, performance and
overall quality of the beta product “released” at the end of Construction phase.
Below you find the activities performed in a typical iteration during Transition phase.
Manage Iteration
Similar to other phases: 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 Transition, but it is recommended that the
Project Manager and team identify any potential issues while delivering the
product to the end-users.
Ongoing Tasks
Submission of change requests during Transition 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 opportunity, requirements will be outlined and detailed accordingly.
However, defects are typically dealt with during Transition, thus a stable release can be accepted by user
community. In the case there is general agreement from Stakeholders, correction of low priority defects can be postponed to subsequent
evolutionary releases.
Develop Solution (for requirement) (within context)
During Transition, 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 into the release
being developed. Despite of that, enhancement requests and defects found in previous iterations may need to be
allocated to Developers.
This is when this activity gets performed (for each change request or requirement within a given context) and allocated
to Developers.
Validate Build
This activity happens in parallel with development of solution for enhancement request and defects (and possibly
remaining requirements), in order to make sure a stable release can be presented to the users community. Users can be
involved in performing tests to accept the release.
Assess and close-out project
Results are assessed against phase objectives, and Stakeholders concurrence about the project objectives is obtained. The team conducts
a retrospective review in order to capture lessons learned and make improvements to the process for next projects. The
project is then closed.
|