This step involves the following work, based on the project's measurement plan:

• Collect the primitive metrics
• Calculate, verify and validate the metrics
• Include the metrics in the status assessment report

During an iteration assessment, metrics are examined, and any actions are decided, which may involve replanning, re-tooling, training, reorganizing, etc... including revisiting the measurement plan. Similarly at the end of a cycle, a "post mortem review" can make sure that some of the metrics collected can be exploited to improve the process, or for estimation purposes. For more information on metrics, see  Guideline: Metrics.

For iterations that span weeks or even months, metrics collection and reporting will be a continuing task, with periodic Artifact: Status Assessments capturing the intermediate results.

Near the end of each iteration, the core project team should meet to assess the iteration, focusing on the following:

• Was the iteration successful in meeting its goals?
  • Were risks reduced or eliminated?
  • Did the release meet its functionality and quality goals? Performance and Capacity goals?
• Are changes to the project and future iteration plans required?
• Have any of the findings captured in the  Artifact: Development Organization Assessment been invalidated by changes during the iteration (as a consequence requiring changes to other work products, such as the project's Development Process)?
• Were there any difficulties with the project's Development Process during the iteration?
• What portion of the current release will be baselined? Reworked?
• Have new risks been identified?
• Have external changes occurred (changes in the marketplace, in the user community, or in requirements)?

Assess the results of the iteration relative to the evaluation criteria that were established for the iteration plan: functionality, performance, capacity, quality measures. Use metrics resulting from the testing tasks and the step Collect Metrics as the basis for the assessment, when available, to quantify the assessment; qualitative measures are adequate for inception and perhaps early iteration, while later elaboration, construction and transition must rely upon specific test measurements to assess quality, performance, capacity, etc. Address other unresolved issues that were captured in the status assessments performed during the iteration, and any others in the Project Manager's Issues List.

If all risks have been reduced to acceptable levels, all functionality has been implemented, and all quality objectives have been met, the product is complete. Good planning and execution are essential to making this occur at the end of the Transition phase.

It is easy for the project team to become so inwardly focused that they are not aware of changes in the world outside the project team. The business may change, adding, changing or removing key requirements. Or a competitor may enter the market with a similar product, causing a change in market timing requirements, features, or target product cost.

Given the current state of the external environment, is the project plan (including milestones) still valid? Have the risks changed, forcing a reconsideration of the iteration plans? Is the right product being built and is the vision still valid? Is the product team on track to deliver that product? Are process changes necessary because of changing external circumstances?

Use the results of these discussions to generate change requests for the Vision, Risk List, the Software Development Plan, the Iteration Plan, or the project's Development Process.

Sometimes an iteration will fall short of expectations because the objectives were set too high. Setting high goals is important, but there is sometimes a fine line between aggressive and unrealistic. Project teams are motivated by goals that cause them to stretch their abilities, but tend to become demoralized if objectives are consistently beyond their reach. Defining goals so that the project team is challenged without being overwhelmed sometimes takes a few iterations in itself, as the team learns to work together and learns its limits.

Examine the evaluation criteria to determine whether they were realistic. Sometimes the benefit of the iteration is in revealing that a particular requirement is not as important as originally thought has tremendous value in itself. Projects are often crushed by complex but low-value requirements imposed by over-eager users enthralled by the latest technology; an iteration or two can re-set their expectations and get them to focus on the functionality which provides real value.

Sometimes the iteration will reveal that a particular feature is very expensive to implement or creates an unmaintainable architecture. The business case for this feature should be revisited to see if the feature should remain in-scope, or perhaps revised to make the requirement reachable in a cost-effective way.

Based on the results of the assessment, generate change requests for the Vision, Risk List, the Software Development Plan, the Iteration Plan, the project's Development Process, and Software Requirements.