As we learned in the beginning of this course, Agile dedicates one of its four values to “Responding to change over following a plan.” This reading aims to clarify some important considerations when implementing a change to the release plan. The best way to think about changing your plan is to break it down into three stages: 1. Identifying a needed change  2. Deciding to make the change 3. Implementing the change ## **Step 1: Identifying a needed change**  First, how do you know if your plan needs to be changed? Here are some aspects of your project that may be candidates for change: scope, time, and costs (or resources). As we previously learned, these are called the “triple constraint,” and they provide a great framework for evaluating change in Agile and traditional projects. - In Agile, **scope** refers to the contents of the product roadmap, the items in the Product Backlog, the intended deliverables of the project, and the intended users or customers. This is the “what” of the project. - **Time** refers to the elements of time or layout of the deliverables over a period of time. This could include the product roadmap timeline, release schedule, or even the Sprint duration. This is the “when” of the project. - **Costs** or **resources** refer to the makeup of the Development Team, project managers, and product owners, and other “business people” as well as the equipment available to create the deliverable. This is the “how” of the project. Agile projects are open to change in any of these three areas, and a needed change could be identified by any project stakeholders, including the Product Owner, Project Manager, Scrum Master, or the Development Team themselves. Sources of identified changes could include: - Customer feedback on early prototypes results in new features and some deleted features (scope change) - Sprint Retrospective identifies an area of understaffing (cost or resource change) - Critical project dependencies or deliverable dates have shifted, resulting in a change to the project roadmap (schedule or time change)  ## **Step 2: Deciding to make the change** Next, how do you decide to actually make the change? There are many decision-making models available to reference. Here are the basic steps involved in most of these models: - **Identify the “decider.”** It is best to have a single person—generally the Product Owner or a senior stakeholder—in the role of decider to ensure consistency and accountability.  - **Develop and share what factors are important to the decision**, and gather supporting data that will help the decider make the decision. - **Openly discuss the benefits and costs of the decision.** Identify areas of uncertainty and capture assumptions. - **Document the decision.** ## **Step 3: Implementing the change** Once changes are approved, it is important to do several things: - **Document the change and decision-making process.** Include meeting notes, pros/cons lists, assumptions, and data that went into making the decision to change the project. - **Capture the change in any affected artifacts**. Update any roadmaps, Product Backlogs, staffing plans, and integration dates, and include a reference to the source of the change so that stakeholders can refer back to it. Consider using revision labels or dates on affected documents like “version 1.2” or “updated on December 20th” so that the team can clearly recognize that the document has changed. - **Share the change with all affected stakeholders.** You can do this through many types of forums: in person at meetings, in documentation and meeting notes, and through email announcements.  - **Monitor the change** **for a certain amount of time.** This ensures that the team is supportive and aware of the change. If the change was not approved during the decision stage, you should still document the information and logic used to make the decision. You may even consider putting a change on hold while you wait for more information to make the decision with higher confidence.