Manage Change Requests¶

(Activity) for Tier: Product

PURPOSE¶

In order to successfully handle and adapt to change in product development, it is critical to have a strategy in place. This activity is intended to provide the structure for formal change request management. That is, managing change for Configuration Items (CI) defined in the project’s Configuration Management Plan (CMP).

WHEN¶

Continuously, as formal requests for change to current sprint development or established product arise.

PARTICIPATING ROLES¶

ACCOUNTABLE
- Product Owner
RESPONSIBLE

INPUTS¶

ENTRY CRITERIA¶

A Configuration Management Plan (CMP) defining formally managed Configuration Items has been established.

SUB-ACTIVITIES¶

Identify Change Requests
- Change Requests (CR) are required and will be used by all development teams to capture change approved by a Change Control Board’s (CCB) approval authority to Configuration Item/s (CI) under formal control. Those CIs under informal control can be modified without formal approval by the approval authority.
  An update to the project’s Configuration Management Plan may be necessary when a CR will result in change to Configuration Items therein.
- Create a Change Request work item providing a description and justification that outlines the perceived value of the change.
  CRs can come from many sources. Specification errors, customer feedback, and discovery of out of date baselines are all candidates for a CR work item.
  
  A CR work item will be used for CI changes that require involving stakeholders in its impact analysis and acceptance or rejection.
  
  CRs must be properly linked and related to the CIs that they are affecting.
Analyze Change Requests
- Consider, analyze, and document impacts to the following areas:
  Architecture – Change requires an update of the current solution architecture.
  
  User Experience Architecture – Change requires an update to current design to match user workflows and thought processes. May also require additional training for users, or updates to training material.
  
  Test – The current testing approach requires modification or there is a significant impact in the testing of the change.
  
  Development – Change requires update to code or development practices.
  
  User Experience Technical Publications – Change requires update to documentation supporting the project/product.
  
  Schedule – Change impacts the scheduled timeline for delivery of the product.
Review Proposed Change Requests
- The team discusses the value and impacts of the CR in order to decide if there is added value to updating the affected CI. An accepted and approved CR will result in change to a CI.
- The designated approval authority will accept or reject changes and the team will effect changes by updating and completing the CR.
  For accepted changes, develop a trackable and traceable plan (e.g., a set of assigned tasks) to update the feature or user story and inform pertinent stakeholders.
  
  For rejected changes, document the reason for the rejection in the CR work item and inform pertinent stakeholders.
  
  Make the scrum master aware of any changes that impact the current sprint or any future work in the backlog.
- Some CRs may require further investigation or deferral, and the CR work item will be placed in the backlog of work to be done.
Track Change Requests
- Define a periodicity to monitor pending and accepted CR work items.
  Backlog Refinement event is favorable to this monitoring.
  
  Ensure that changes to CIs conform to stakeholder expectations.

OUTPUTS¶

In-work or completed CR work items are required and must be traceable to those CIs where the requested change has been affected.
Update(s) to Configuration Management Plan when necessary

EXIT CRITERIA¶

All CR work items have been reviewed following steps in “Review Proposed Change Requests” sub-activity above.