The fourth of five (5) tasks in Planning Level 3 is focused on the execution of the medium-term planning event. During this event, previously estimated work undergoes a final review, and the Team(s) make a commitment to delivering some number of Features during the next medium-term increment. In other words, they set the scope for the Solution's next Release.
Overview
This is the task most people think of when referring to "Release Planning". This is an event, during which the scope of the next, upcoming Release is set by the Solution Manager, along with the Release Manager and Team(s) as they select which Features will be included. Setting this Release scope helps to drive subsequent Sprint Planning as well as other meduim-term Solution / Project tasks such as Test Planning, Training Development and Communications.
This planning task, and the subsequent work which takes Stories & Bugs from "Ready" to "Done" is managed by the corresponding Iterative Solution Implementation task IT3: Feature Release.
Release Artifacts
For most Solutions:
- A Release is simply defined as some set number of Sprints' worth of development, with each Sprint being conducted over a 2-week period. Thus, for a Solution with a Quarterly Release schedule that set number is 6 Sprints; meaning 12 weeks' or 1 Quarter's worth of effort. For a Solution with a Bi-Monthly Release schedule, that set number is 4 Sprints (8 weeks); for one with a Monthly Release schedule that set number is 2 Sprints (4 weeks).
- A Release Plan identifies the Features to be delivered during a given Release, after giving consideration to such things as priority, Team Capacity, and dependencies.
- A Release Backlog is the list of Features and their related Stories that are to be completed and delivered by the end of the given Release. The Features and Stories are identified as being in a Release by their Release ID value in the WMS.
The Release Plan gives the Team and all stakeholders a common understanding about what needs to be achieved, and when. It guides the Team to make decisions during detailed planning (e.g., IT2: Story Analysis) and helps to prioritize Stories. It also helps to resolve conflicts and guide the Team(s) toward the right balance on trade-offs.
Features and benefits are used to express the objectives presented in Release Planning. To limit work-in-progress to near term Solution increments (e.g., Sprints or minor releases), the Solution Manager (or supporting Solution Owner(s)) would typically present only the Top 10 "Ready" Features for potential consideration.
During Release Planning, Features may be split as needed and Stories created to implement the Feature. Scope can be negotiated. If a Feature cannot be split and scoped to fit within the next increment (i.e. Release), it will remain in the Solution Backlog to be re-valuated before the next (or some subsequent) Release Planning Event.
For additional details on Release Planning, see the Scaled Agile Framework - Program Increment Planning.
Historical Releases & Team Capacity
The list of all current and former Solution Releases (known as 'Versions' in Jira) can be found in the WMS Release Report. For each Release, information such as: the number of Features & Stories within the Release; progress towards completion; and Release Notes (list of Features and Stories within the Release) is available.
Historical Releases provide an excellent reference to assist in planning future Releases. One of the main values to come from historical Releases is the cumlative number of Points the Team earned (i.e., the amount of work claimed as "Done"). Expect the actual number of Points to vary Release-by-Release, but a running average of the prior 3 Releases will determine a Team's capacity.
Capacity is a key metric in iterative delivery. It is a measure of a Team's productivity and, ideally, should trend upward as members of a Team learn to work together better. If the trend is down, that's an indication that some management attention is warranted to assess why the Team is becomming less efficient. There are many reasons why this may be the case, many of which are not with the Team's control. Getting to the root cause will help improve overall delivery value.
Capacity is not meant to be some target defined by management for a Team to achieve. Rather, it is a proxy for the Team's overall work, including Feature & Story refinement and quality of delivery.
When planning a Release, comparing:
- the Points-equivalent of the cumulative T-Shirt sizes associated with the Features selected; against
- a Team's Capacity;
will provide a guide as to what may be too little, or too much, work within the Release.
Tips for Better Planning
- Ensure Leadership engagement - the Epic Owners and Business / Process Owner(s) are key participants at this point. A lack of engagement by these individuals will diminish the veracity of the work to be accomplished, likely wasting valuable time and money.
- Consider using independent facilitator(s) - the prioritization and selection of Features can be a very political process. Allow Solution Management to remain above this by using external or independent resources to faciliate the Release Planning Event.
Release Planning Event
Release Plans are created during the periodic Release Planning Event. This event marks the beginning of each Release cycle. It sets the expectations for everyone of what is to be achieved over the next medium-term of the Solution (4, 8 or 12 weeks). It also synchronizes and mobilizes the resources needed to achieve those expectations.
Refer to the appropraite Timeline Template to see the Release Planning Event in the context of a Quarterly Release Schedule, a Bi-Monthly Release Schedule, or a Monthly Release Schedule.
Event Inputs
Inputs to each Release Planning Event include the mostly recently updated (via prior Planning Level activites):
- Solution Vision - to maintain focus of Phase objectives. Over time additional scope will want to creep into the Solution. That new scope may be fine, but only after a new Phase begins or a Solution Change Request (SCR) (which may have updated the Vision) is appropriate processed. For now, planned work should only be committed to when it both supports the Vision and aligns to an existing Epic on the Epic List. Do not permit future scope work to impede current scope objectives.
- Solution Roadmap - Release planning does not start with a blank slate. Preparations should have been made by the Solution Manager, working with Solution Owner(s), Epic Owners, Business Owners and/or Process Owners. The Roadmap should state what leadership desires, though not necessarily what can be achieved.
- "Ready" Features - as defined by the Feature Planning Board, these are the short-list of Features which have been refined and which are now suitable for delivery. Only "Ready" Features can be selected for inclusion in the Release, regardless of their position on the Roadmap or whether they've otherwise been targeted for a Release. If desired Features are not "Ready" for Build, Test & Deply then prioritize their Analysis & Design so they become "Ready" for a subsequent Release. Never attempt to conduct both Analysis & Design and Build, Test & Deploy of any Feature within a single Release.
Event Participants
This event is when impactful decisions are made. As such, leadership must be involved along side those who will commit to, and be responsible for, executing the work to accomplish Release objectives. Involving almost everyone associated with the Solution helps to clarify communications, to identify and manage risks and opportunities, and is expected to make overall delivery more effective.
- Solution Management - The specific Product-, System- or Service-Manager along with the general Solution Manager if one exists; the Release Manager; the Product-, System or Service-Owner(s); and Scrum Master(s).
- Solution Customers - Especially those for whom new Business Value may be delivered within the Release. This should include all Epic Owners, affected Business / Process Owners, Sponsor(s)  and/or Customer representatives.
- Architects - including the relevant Product-, System- or Service-Architect(s) as well as any associated Solution Architects. A courtest invitation should also be extended to the Enterprise Architect(s) who may have reason to participate.
- Solution Delivery - including members of all associated Delivery Team(s) and as well as DevSecOps members or representative(s).
Prior to Each Event
To prepare for the Event Tasks, prior to each Release Planning Event, the Release Manager should ensure that:
- All items have been removed from the 'Build' column of the Feature Release Board; either progresed to a Candidate Release, or regressed back to "Ready"; and
- The Release IDs of any item regressed back to the Solution Backlog is updated to reflect its new, targeted Release.
This should leave the 'Build' column of the board empty, ready to have the set of Features which will make up the next Release selected into it.
Event Tasks
During each iteration of this event, participants will progress through the following tasks.
Day 1:
- Synchonize Participants:Â Begin by getting everyone on the same page as to where is the Solution currently is in terms of Business Context, Solution Vision, Solution Architecture, Environments and Standards.
- Draft Planning: using the event inputs (see above), individual Teams produce draft plans. This involves them selecting prioritized and "Ready" Features from the Solution Backlog, breaking down selected Features into Stories (or completing any breakdowns previously started), and aligning those Stories to anticipated Release Sprints. Expect this task to take about 1/2 day.
- Management Review: The Release Manager and Scrum Master(s) review the draft Team plan(s) to identify any problems with scope, timing, dependencies, and resource constraints. They will make or propose alternatives to adjust for identified constraints and either make, or highlight the need for, decisions required prior to finalizing the planned work.
Day 2:
- Final Planning: Participants will review any adjustments, decisions or changes resulting from the preceding Management Review. Individual Team(s) will then continue planning, polishing their Day 1 Draft Plan into a Day 2 Final Plan. When both the Team and Business / Process Owner agree upon the Team-level plan, it becomes finalized and accepted.
- Reviews, Updates & Acceptance: Individual Team plans are now reviewed by all participants. At this point participants seeks to resolve, own, accept, or mitigate identified risks. If any re-work of the plan is required, it is done now. Following this, all participants vote on whether or not to accept the plan. There should have been enough consensus throughout the planning process that all are on board. If agreement is not reached, adjust the plan(s) until acceptance is achieved.
- Retrospctive: An internal review by all participants of how this planning cycle went. What worked well, and should be reinforced; what did not work well and should be changed for the next cycle?
Event Outputs
As desribed at left:
- Release Plan - A summary of the Features to deliver, their sequencing, dependencies and Team alignments. Should be suitable for subsequent planning and development of related Testing, Training, Rollout and Communication materials.
- Release Backlog - A subset of the Solution Backlog which identifies the Features, Stories, Bugs and any other objectives to be delivered over the medium-term (i.e., by Release end). This simply means each item is tagged in the WMS with the same, unique Release ID.