Inception is ideally short, such as a few days. Iterations are possible, but rare. Activities could include a short requirements workshop, 10% of the requirements captured in detail (the most architecturally influential ones), a "top ten" high-level requirements list, and a first draft of the vision and business case for the project. If this phase is long, it is usually a sign of excessive up-front specifications or planning.
In elaboration, the core, architecturally significant elements are programmed and tested in a series of short timeboxed iterations, and by its end a semi-reliable plan and estimate is possible. This phase includes programming work, not only requirements or design modeling. In addition to development, with feedback from the growing system, there may be a series of short requirements workshops (one per iteration) to refine most of the requirements. This is a step of discovery and creativity; when complete, the core of the system and most requirements have stabilized through an iterative, evolutionary process.
In construction, the remainder of the system is built in short iterations on top of the solid foundation laid in elaboration. Requirements may still change, but ideally the big surprises were provoked and discovered earlier in elaboration. Other activities include alpha testing, performance tuning, and document creation (for example, user aids).
In transition, the system is ultimately deployed. First, a release candidate is exposed for review and feedback. This may occur in several iterations. Finally, there is deployment, that may include distribution over various channels, education, parallel run with an older system, data conversion, and so on.
The UP identifies milestone objectives in a project that define the boundaries of these phases. These come from the work of the Barry Boehm, in [Boehm96]. Boehm called the end of inception the Life Cycle Objectives (LCO) milestone. The end of elaboration was called the Life Cycle Architecture (LCA) milestone.
 Boehm and the UP creators have a long history of collaboration.
Each phase may contain multiple iterations. The milestone goals of each phase are described in Table 9.3, and an example of phases and iterations is shown in Figure 9.5.
Figure 9.5. UP phases; the size of the relative effort in each discipline is suggestive, not literal
Table 9.3. UP phases
Agreement on scope, vision, and priorities.
Some risks identified.
A plan to start elaboration exists.
Establish a common vision.
Typically a very short phase, such as a few days or weeks.
A first requirements workshop might be held.
The vision, requirements, and architecture are stabilized.
The core executable architecture is implemented; major risks are mitigated.
The majority of requirements are defined.
Estimates and coarse-grained plan are defined.
Build and test the risky core.
This phase contains significant production programming and testing, combined with evolutionary requirements and design work.
Usually composed of several iterations. In addition to programming, perhaps a series of requirements workshops; one per iteration.
Semi-reliable plans and estimates at end of elaboration.
System is believed ready to be deployed.
Stakeholders are ready for deployment.
Build and test the rest.
Typically the largest set of iterations. As in elaboration, major testing occurs in each iteration.
System is deployed.
Users are satisfied.
Beta testing, release candidate evaluation, training.
Figure 9.5 shows an example of iterations across the phases: three iterations in elaboration and 10 in construction. As usual, iterations are not necessarily the same length. Often, early elaboration iterations are longer (e.g., three weeks) due to the demands of creative and unpredictable discovery. Later construction iterations could be one or two weeks long. The resources or staffing also varies. Ideally, the elaboration phase is staffed by a small, cohesive, co-located team who shape the core. During construction, larger teams and more parallel development may occur. See Figure 9.6.
Figure 9.6. resources across phases; the size of the relative resource use is suggestive, not literal