Guideline: Submitting Change Requests
This guideline describes the type of information that is typically captured on a change request. This information is used to prioritize and scope the work required to implement the change and to monitor progress.
Relationships
Related Elements
Main Description

Background

Change requests typically have a lifecycle. They are raised, reviewed, accepted or rejected, implemented, verified, and closed. These states define the status of the change request at a particular point in time, and represent critical information for tracking progress. Other sets of states are possible.

During review of a change request, the goal is to assess the technical, cost, and schedule impact of implementing the change. The technical impact assessment includes the determination of which work products are affected and an estimate of the level of effort required to change and verify all affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately, whether the change request will be accepted or rejected.

If accepted, the implementation and verification of the change request will be assigned to an iteration in the same manner as any other work item.

The current process uses the Artifact: Work Items List to capture, prioritize, and track the change requests using the attributes defined for that artifact.

Submitting change requests

When submitting a change request, provide as much information as possible to enable a speedy review and disposition. At a minimum, all change requests should include the following information:

  • ID: A unique identifier for the change request to simplify tracking. If you are using some form of change tracking tool the tool will assign a unique ID.
  • Brief Description: A name that summarizes the change request.
  • Detailed Description: A detailed description of the change request. For a defect, if you can provide information that will help reproduce the defect please do so. For an enhancement request, provide a rationale for the request.
  • Affected Item: The affected artifact and version.
  • Severity: How severe is this issue (show stopper, nice to have, and so on)?
  • Priority: How important this request is, in your opinion.

Depending upon the system you are using, the names of these data elements may differ. However, this information is required, in one form or another, to permit speedy review and disposition of the change request.