There is no magic in SAFe … except maybe for Release Planning.
Release Planning Abstract
The Agile Manifesto states: the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In SAFe, we take this to the next level via Release Planning, the seminal, cadence-based synchronization point of the Agile Release Train. Release planning is a routine, program-scale, face-to-face event with a standardized agenda that includes presentation of vision, team planning breakouts, and commitment to PI and release objectives for the next PI timebox. Facilitated by the Release Train Engineer, attendees typically include ALL members of the program. It takes place over a one and a half to two-day period at each PI boundary. In geographically distributed programs, the event may occur at multiple locations simultaneously, with constant communication between the locations.
Release planning is the seminal, cadence-based event that serves as the heartbeat of the Agile Release Train. It is integral and essential to SAFe (if you are not doing it, you are not doing SAFe). At scale, this can be quite a significant event, as Figure 1 below implies:
Release Planning delivers innumerable business benefits, including:
- Face-to-face planning provides for high bandwidth communication
- It helps build the social network that the ART depends upon
- Aligns development to business via Team and Program objectives and interaction with Business Owners
- Identifies dependencies, and fosters cross-team and cross-program coordination
- Provides the opportunity for “just the right amount” of Architecture and UX guidance
- Matches demand to capacity, eliminates excess WIP
Outputs of the planning process include: Team PI Objectives for each individual team, a synthesized and summarized set of Program PI Objectives, including any release commitments, a Program Board (plan) identifying milestones during the period, and a vote of confidence/commitment from the entire program to these objectives. After planning, the Roadmap is updated to reflect the results and forecast for future PIs.
One primary purpose of release planning is to gain alignment between business owners and the program teams to a common, committed set of Program PI Objectives and Team PI Objectives for the next PI timebox, including identification of any specific Release commitments during that period. An additional benefit of the process is program-wide team building, which helps create the social fabric necessary to achieve high program performance. An overview of this process appears in Figure 2.
In addition, as planning is based on known velocities, release planning is a critical step in continuously assessing WIP, and shedding excess WIP whenever necessary.
Inputs to the event include the Roadmap and Vision, the top 10 Features from the Program Backlog, and other business context. Attendees include all the team members and program stakeholders, including the business owners. Outputs include four primary artifacts:
- A set of “SMART” Team PI objectives for each individual team, created by the team, with business value assigned by the business owners
- A synthesized and summarized set of Program PI Objectives
- A PI Plan, which highlights the new features, anticipated delivery dates and any other relevant milestones, aggregated from the team objectives
- A vote of confidence/commitment from the entire program to these objectives
This repetitive, “rolling-wave planning” process guides the program through the inevitable technical obstacles and twists and turns of the marketplace.
The Release Planning meeting is a major event. As such, each requires preparation, coordination, and communication. In addition, as the first planning meeting may be the enterprise’s first introduction to agile-in-the-large development, even more intensive readiness steps may precede it.
- Organizational readiness – Strategic alignment and organizational readiness
- Content readiness – Management and development preparedness
- Facility readiness – The actual space and logistics for the event
Below are descriptive highlights from the Release Planning Readiness Checklist in Ref , Appendix C. See Chapter 15 of Ref for additional details.
Prior to planning, it’s important to insure that: programs have reasonable strategy alignment among participants, stakeholders, and business owners; teams will be aligned to the Value Stream; and critical roles are assigned. To address this, preparedness questions include:
- Planning scope and context – Is the scope (product, system, technology domain) of the planning process understood? Do we know which teams need to plan together?
- Business alignment – Is there reasonable agreement on priorities among the business owners?
- Agile Teams – Do we really have Agile Teams? Does each have dedicated developer and test resources and an identified Scrum Master and Product Owner?
It is equally important to assure that there is clear Vision and context, and the right stakeholders can participate, including:
- The executive briefing – Defines current business context
- Product vision briefing(s) – Briefings prepared by product managers , including the the top ten Features in the Program Backlog
- Architecture vision briefing – Briefing prepared by the CTO, Enterprise Architect, and/or System Architect to communicate new Architectural Epics, Features, and Nonfunctional Requirements
Securing the physical space and technical infrastructure necessary to support the large number of attendees isn’t trivial either, especially if there are remote participants. Considerations include:
- Facility – roomy enough for all attendees with breakout rooms if necessary
- Facilities/tech support – Facilities/tech support people identified and reachable during setup, testing, and the event
- Communication channels – For distributed planning meetings, primary and secondary audio, video, and presentation channels must be available
The Release Planning Event
The meeting generally follows a standard agenda, such as that in Figure 3. Descriptions of each agenda item follow.
Business Context. A senior executive/line-of-business owner presents the executive briefing.
Product/Solution Vision. The product manager(s) responsible for the planning domain present the current product/solution vision.
Architecture Vision and Development Practices. The CTO, enterprise architect, and/or system architect presents the architecture vision. Further, a senior development manager may present agile-supportive changes to such things as standard practices, test automation, and continuous integration.
Planning Requirements. The Release Train Engineer/facilitator presents the planning process and plan acceptance criteria.
Team Breakouts #1. The group divides into teams and creates their draft plans. In breakout #1, teams estimate their capacity (velocity for each sprint), develop and refine the Stories they need to realize the features, identify risks and dependencies, and draft their Team PI Objectives.
Draft Plan Review. During the tightly timeboxed draft plan review, teams present key planning outputs including draft objectives, potential risks and impediments, and dependencies. During this review, business owners, peers and stakeholders also provide input to be used during the planning adjustment meeting and team breakout #2.
Management Review and Problem Solving. It is likely that the draft plans present challenges like scope, resource constraints, and dependencies. During this review and problem solving meeting, management negotiates scope, makes necessary changes, and resolves these challenges. The RTE keeps key stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.
Planning Adjustments. During the planning adjustments presentation, management team members describe any necessary changes to scope and resources.
Team Breakouts #2. Teams continue planning based on their plan from the previous day, with appropriate adjustments. They finalize their objectives for the PI, to which business owners assign business value.
Final Plan Review. During the final plan review, all teams present their plans to the group. At the end of each team’s time slot, the team states their risks and impediments, but there is no attempt to resolve them in this short time slot. If the plan is acceptable to the business owners, the team brings their PI objective sheet and program risk sheet to the front of the room so that all can see the aggregate objectives unfold in real time.
Addressing Program Risks. During planning, teams have identified critical risks and impediments that could affect their ability to meet their objectives. These are addressed in a broader, management context in front of the full group. One by one, risks are categorized into one of the following group and addressed in a clear, honest, and visible manner:
- Resolved – The teams agree that the issue is no longer a concern
- Owned – The item cannot be resolved in the meeting, so someone takes ownership
- Accepted – Some risks are facts or potential occurrences that simply must be understood and accepted.
- Mitigated – Teams can identify a plan to mitigate the impact of an item
Confidence Vote. Once program risks have been addressed, teams vote on their confidence in meeting their release objectives. Each team conducts a “show of hands, five-finger vote”. If the average is three or four fingers, and management should accept the commitment. If the average is fewer than three fingers, then planning adjustments are made and plans are reworked.
Plan Rework if Necessary. If necessary, teams rework their plans as long as it takes for commitment to be reached. This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.
Planning Retrospective & Moving Forward. Finally, the RTE leads a brief meeting retrospective to capture what went well, what didn’t, and what can be done better next time. Following this, next steps are discussed, including capturing objectives and stories in the agile project management tooling, the schedule of upcoming key activities and events … and cleaning up the room!
Deliverables of a Successful Event
A successful event delivers three primary artifacts:
1. A set of “SMART” objectives for each individual team, created by the team, and with business value as set by the business owners. This may include stretch objectives, which are goals built into the plan, but not committed to by the team. Stretch objectives provide the flexible capacity and scope management options needed to increase reliability and quality of program execution. A sample of one team’s release planning artifacts is illustrated in Figure 3.
2. A “Program Board (Plan),” which highlights the new features, anticipated delivery dates and any other relevant milestones, aggregated from the team objectives, as illustrated by Figure 5.
3. A vote of confidence/commitment from the entire program to these objectives
Thereafter Product Management can update the program Roadmap, based on the objectives for the planned PI.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chap. 16.
Last update: 2 August, 2014
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, visit the Permissions FAQ and Form.