The Iteration Plan prepared at the start of the iteration can select only from what is known at the time. This will be an increment of the total capability required (functional and non-functional requirements), and Change Requests left over from previous iterations. The Project Manager can then determine the resources and schedule for the iteration. Allowance for defects should be built into the plan for the iteration, either implicitly, in the effort allocated to the production of an artifact, or explicitly, in particular work packages. It is recommended that the latter method be adopted. and the Unified Process for EDUcation contains activities to make this possible (such as Activity: Fix a Defect in the Implementation discipline).
Although the priority for fixes is assigned by the Change Control Manager, Project Manager may still exercise some planning discretion in deciding when fixes should be made - but in general, an attempt should be made to correct defects in the iteration in which they are discovered, and it should be possible to do this with the resources planned at the start of the iteration. There will inevitably be some (discovered) defects left unfixed at the end of an iteration (because an iteration should be timeboxed), but for the iteration to be deemed a success, it is not likely that many of these would be severe or rated high priority for other reasons.
Little allowance can be made, however, for other than trivial enhancement requests, that arise unexpectedly. If such a Change Request for a substantial enhancement is sanctioned for the current iteration, the Project Manager will almost certainly have to re-plan, either by pushing off some planned capability to the next iteration, or by finding extra resources to make the change. Usually, such requests for enhancements will be held over for the next iteration, or even later ones, and then be made part of the regular iteration planning cycle.
The Change Request is examined and the Project Manager decides, based on its type, priority and severity, in which iteration it should be fixed. If the Change Request is to be held until a later iteration, the Project Manager simply re-plans the future iterations (in the Software Development Plan), so that the impact of the Change Request is understood now, and resource acquisition activities can be initiated as early as possible, to avoid unpleasant surprises later.
The Project Manager decides which organizational position(s) should be responsible for implementing the change.
The Change Request should already contain a description in outline of the required change (because the Change Request has already been analyzed and approved). This step refines that description into an unambiguous statement of what is to be done and produced.
The Project Manager, in consultation with those responsible for the Change Request, refines the effort and other resource estimates in the Change Request into firm planning estimates, to which the responsible staff are expected to commit.
If the Change Request is to be implemented in the current iteration, the Project Manager, in consultation with those assigned responsibility, will set a start date and expected duration for the work.
If necessary, the current Iteration Plan is revised, and any impact on future iterations should be reflected in the Software Development Plan.
The Work Order(s) defining the work to be done, schedule, responsibility, and so on, are issued by the Project Manager. The work package (in the work breakdown structure) against which the effort is budgeted, is identified in the Work Order.