#### 7.2.2.2 Release Plan A Release Plan documents the high-level UX and development milestones. It gives information of what will be released and when, based on the information the Project Core Team (PCT) has in a specific point in time. The Release Plan results from the initial overall project planning effort during the PM2 Initiating and Planning phases and should be adjusted according to the progress and feedback from the Agile Project Core Team (A- PCT). The main purpose of the Release Plan is to: - plan the release of usable versions of the solution; - provide a high-level plan with the main goals to be achieved, including major features to deliver; - offer visibility to the risks, issues, decisions, changes, constraints and assumptions related to the development aspect, such as dependencies on other projects and other information systems; - assist when scheduling transition activities (e.g. deployment strategy and activities); - assist when scheduling Business Implementation activities (e.g. training activities). Releases introduce a timeboxed rhythm to the construction efforts, providing (some level of) predictability for both the Agile Project Core Team (A-PCT) and the rest of the stakeholders. The Release Plan facilitates the management of dependencies that the information system being developed may have with other projects, information systems or operations activities. For each planned release, transition activities must be defined, the environment targeted by the release is prepared and the end-users are ready to use the delivered solution. These activities should be documented and aligned with the PM2 Transition Plan. Releases that are meant to be made available to the overall requestor organisation must also have associated the needed Business Implementation activities, ensuring a successful information system’s roll-out. These activities should be documented and aligned with the PM2 Business Implementation Plan. | Key Participants | Description | |:------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [[Project Manager (PM)]] | Accountable for the alignment between the delivery strategy reflected in the Release Plan and the overall project vision and all relevant milestones described in the Project Charter. | | Team Coordinator (TeCo) | Responsible for the development of the Release plan, supported by the PrOw - who provides guidance based on the prioritised Work Items List <br> (WIL) - and the remaining Agile Team Members (ATeM), who provide additional inputs on viability of the plan. | | Agile Team Member (ATeM) | Supports the Team Coordinator (TeCo) by providing inputs related to the plan’s viability, including dependencies between the several Work Items. | | Architecture Owner (ArOw) | Supports the Team Coordinator (TeCo) by providing inputs related to the solution’s global architecture and building blocks that may exist and impact the Release Plan. | | Business Manager (BM) | Informed by the Product Owner (PrOw) on the updated Release Plan. | | Product Owner (PrOw) | Supports the Team Coordinator (TeCo) by providing the delivery strategy of the business as a set of milestone dates, the release objectives and foreseen features and the corresponding Work Items. | **Guidelines** - **Build a Release Plan as early as possible** – As the main driver to deliver the solution, hold the first Release Planning ceremony to establish the initial Release Plan as soon as possible, preferably in the beginning of the Planning phase. - **The Release Plan reflects the Solution’s release strategy** – The Release Plan is more than just a calendar of dates for major releases with the key functionalities. With the Release Planning ceremony playing a critical role, the Release Plan reflects the overall strategy (marketing, operational, economic, legal, etc) to release the solution to the users’ community. - **Provide different levels of detail** – Because different types of audience are interested in the Release Plan, different levels of detail must be provided. For example, the Appropriate Governance Body (AGB) is interested in the several releases planned and their major objectives to validate if the Release Plan is aligned with the overall strategy. However, the Product Owner (PrOw) needs to know which work items will be delivered in each release, as this will help to verify which part of each feature will be released and when. - **Revisit the plan after each Iteration** – At the end of each iteration, some new inputs will generate new work items in the Work Items List (WIL) as part of the learning process materialised by ceremonies like the Iteration Review and Iteration Retrospective. As an example, the updated data regarding the velocity of the team must be reflected in the Release Plan in order to continuously evaluate its feasibility. - **Release Planning ceremony** – The outputs of the several steps of the Release Planning ceremony contribute to an updated Release Plan. Work items added, updated or removed from the Work Items List (WIL) with the corresponding relative estimates provided by the Agile Team Members (ATeM) must be incorporated in the Release Plan to reflect the most up to date scenario; - **Release Plan Feasibility** – New facts, data, decisions, will constantly surface throughout the project impacting the size of the Work Items List (WIL) and the team’s velocity. These two elements evaluate the Release Plan’s feasibility and allow the business stakeholders to make adjustments when required. Also, using different sets of data can help creating different possible scenarios, like using an optimistic and pessimistic velocity. - **Have a Deployment Plan** - Plan the strategy for deploying the software (and its updates) into the production environment as early as possible, because it may have an impact on the Work Items List (WIL) and the Release Plan. This is also true when specific operations and support departments are responsible for managing the overall corporate deployment system. Having a Continuous Delivery Pipeline as part of a DevSecOps initiative can streamline this process and dramatically reduce its complexity. - **Make assumptions clear and visible** – The velocity of the team and the pre-defined size of each iteration are two examples of elements that impact the way a Release Plan is understood. When defining the Release Plan, these elements must be clearly visible and identified as the current Release Plan’s assumptions. ![[7.2.2.2 Release Plan — Inputs and main roles - 1.png]] ![[7.2.2.2 Release Plan — Inputs and main roles - 2.png]]