The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

– Agile Manifesto Principle #6

PSI/Release Planning Abstract

PSI (Release) Planning is the seminal, cadence-based synchronization point of the Agile Release Train (ART). 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 PSI/release objectives for the next PSI timebox. Typically 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 PSI boundary. In geographically distributed programs, the event may occur at multiple locations simultaneously, with a constant updating from location to location.

A successful event delivers three primary artifacts:

A set of “SMART” objectives for each individual team, created by the team, and ranked by business value by the business owners
A PSI 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

Thereafter Product Management can update the program roadmap, based on the objectives for the next PSI.

Details

The purpose of the PSI/Release Planning Meeting is to gain alignment between business owners, product management, architecture, development, and key stakeholders of a program to a common, committed set of Objectives for the next PSI timebox. An additional benefit of the process is program-wide team building, which helps create the social fabric typified in high performance programs.

The Release Planning Meeting is a major event. As such, each requires considerable preparation, coordination, and communication. In addition, as the first planning meeting may be the enterprises first introduction to agile-in-the-large development, even more intensive readiness steps may precede it.

Release Planning Readiness

Preparation for a success event is required in three major areas:

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 [1], Appendix C. See Chapter 15 of Ref[1] for additional details.

Organizational Readiness

Prior to planning, it’s important to insure that: programs have reasonable strategy alignment among participants, stakeholders, and business owners; teams can be aligned to the value stream; and critical roles can be adopted. 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 and Product Management?
Agile Teams – Do we really have Agile Teams? Does each Feature/Component team have dedicated dev and test resources and an identified Scrum Master and Product Owner?

Content Readiness

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 and Investment Themes
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

Facility Readiness

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

Figure 1 provides a typical agenda. Descriptions of each agenda item follow.

Figure 1 Sample Release Planning Agenda

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 PSI Objectives.

Draft Plan Peer Review. During the tightly timeboxed draft plan review, teams present key planning outputs including draft objectives, potential risk and impediments, and dependencies. During this peer review, business owners 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 /facilitator keeps key stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.

DAY 2

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 PSI, which are then ranked by value by the business owners.

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 PSI 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

PSI 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/facilitator 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 ranked by business value by the business owners. This may include stretch goals, which are goals built into the plan, but not committed to by the team. Stretch goals provide the flexible capacity and scope management options needed to increase reliability and quality of program execution. A sample of one teams release planning artifacts is illustrated in Figure 2.

Figure 2 Release Planning team artifacts

2. A PSI “Program Plan”, which highlights the new features, anticipated delivery dates and any other relevant milestones, aggregated from the team objectives, as illustrated by Figure 3.

Figure 3. Example Program Board

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 next PSI.

Though it eventually becomes routine, the Release/PSI event is a critical event, one that affects the health and outcome of every program. Proper preparation and effective facilitation are keys to a successful event—an event that produces program alignment via clear and actionable agreement on the near-term objectives.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chap. 16.

Last update 24 March, 2013