Activity:  Schedule and Assign Work

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 Rational Unified Process 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.

Allocate Change Request to an Iteration

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.

Assign Responsibility

The Project Manager decides which organizational position(s) should be responsible for implementing the change.

Describe Work and Expected Outputs

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.

Budget Effort and other Resources

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.

Set Schedule

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.

Re-plan

If necessary, the current Iteration Plan is revised, and any impact on future iterations should be reflected in the Software Development Plan. As a result of the re-planning, the Project Manager may have to invoke the Activity: Handle Exceptions and Problems, to bring the project state into line with the new plans, particularly if the current iteration is affected by a resource shortfall or slippage of planned capability to later iterations.

Issue Work Order

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.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process