Future product development tasks can’t be pre-determined. Distribute planning and control to those who can understand and react to the end results.
—Michael Kennedy, Product Development for the Lean Enterprise
There is no magic in SAFe . . . except maybe for PI Planning.
PI Planning Abstract
A principle of the Agile Manfesto states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” SAFe takes this to the next level via PI Planning, the seminal, cadence-based synchronization point of the Agile Release Train (ART). PI planning is a routine, face-to-face event with a standardized agenda that includes presentation of business context and Vision, followed by team planning breakouts wherein the teams create the plans for the upcoming Program Increment (PI). Facilitated by the Release Train Engineer (RTE), attendees include all members of the ART whenever possible. It takes place over one and a half to two days and occurs within the IP Iteration, which means that it doesn’t affect the timebox, scheduling, or capacity of other iterations in the PI. The result is a commitment to an agreed-to set of Program PI objectives for the next PI. In geographically distributed ARTs, the event may occur at multiple locations simultaneously, with constant communication between the locations.
In multi-ART Value Streams, Pre-PI Planning meetings are held to set the context and input objectives for the ART PI planning sessions. Post-PI Planning sessions are used to integrate the results of the ARTs that contribute to the Value Stream.
PI 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 implies:
PI planning delivers innumerable business benefits; its activities include:
- Establishing high-bandwidth communication across all team members and stakeholders
- Building the social network the ART depends upon
- Aligning development to business via business context, Vision, and Team and Program PI Objectives
- Identifying dependencies and fostering cross-team and cross-ART coordination
- Providing the opportunity for “just the right amount” of Architecture and User Experience guidance
- Matching demand to capacity, eliminating excess WIP
- Accelerating decision-making
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. PI planning has three primary outputs:
- A set of “SMART” team PI objectives for each individual team, created by the team, with business value assigned by the Business Owners, and a synthesized and summarized set of program PI objectives
- A “program board,” 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
In addition, in large Value Streams, multiple ARTS typically plan contemporaneously. Such events are typically bracketed by Pre- and Post-PI Planning events, which provide alignment and coordination of the ARTs to a common Solution purpose. These events are discussed briefly later in this article.
PI planning is a major event that requires preparation, coordination, and communication. Event attendees, including Product Management, Agile Teams, System and Solution Architect/Engineering, the System Team, and other stakeholders must be notified and well prepared.
Preparation for a successful event is required in three major areas:
- Organizational readiness – Strategic alignment and teams and trains setup
- 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 , Appendix C. See Chapter 15 of  for additional details.
Prior to planning, it’s important to insure that Programs have reasonable strategy alignment among participants, stakeholders, and Business Owners; teams are 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 have Agile Teams? Does each have dedicated developer and test resources and an identified Scrum Master and Product Owner?
It is equally important to ensure that there is clear vision and context and that the right stakeholders can participate. Therefore the PI planning must include:
- The executive briefing – A briefing that defines the current business context
- Product vision briefing(s) – Briefings prepared by Product Management, including the top ten Features in the Program Backlog
- The architecture vision briefing – Briefing prepared by the CTO, Enterprise Architect, and/or System Architect to communicate new Enablers, 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 – This must be roomy enough for all attendees, with breakout rooms if necessary
- Facilities/tech support – These people need to be identified in advance 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 meeting generally follows a standard agenda, such as that in Figure 2. Descriptions of each agenda item follow.
Business Context. A senior executive/line-of-business owner describes the current state of the business and presents a perspective on how well current solutions are addressing current Customer needs.
Program Vision. Product Management presents the current program vision—typically represented by the next top 10 upcoming features—and highlights any changes from the previous PI planning meeting, as well as any upcoming Milestones.
Architecture Vision and Development Practices. System Architect/Engineering presents the architecture vision. In addition, a senior development manager may present Agile-supportive changes to development practices, such as test automation and Continuous Integration, that are being advanced in the upcoming PI.
Planning Context. The Release Train Engineer presents the planning process and expected outcomes of the meeting.
Team Breakouts #1. In the breakout, teams estimate their capacity (velocity) for each Iteration and identify the backlog items they will likely need to realize the features. Each team creates their draft plans, visible to all, iteration by iteration. During this process they identify risks and dependencies and draft their initial team PI objectives. The team also adds the features to the program board.
Draft Plan Review. During the tightly timeboxed draft plan review, teams present key planning outputs, including draft objectives, potential risks, and dependencies. Business Owners, Product Management, and other teams and stakeholders review and provide input.
Management Review and Problem-Solving. It is likely that the draft plans present challenges such as scope, resource constraints, and dependencies. During this review and problem-solving meeting, management negotiates scope and resolves these challenges by agreeing to various planning adjustments. The RTE facilitates and keeps key stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives. In multi-ART value streams, a similar meeting may be held after the first day of planning to solve cross-ART issues that have come up, or, alternatively, the RTEs of the affected trains talk with each other to raise issues that are then resolved in the train management problem-solving meeting.
Planning Adjustments. The next day, the meeting begins with managers describing any changes to planning scope and resources.
Team Breakouts #2. Teams continue planning based on their plan from the previous day, with the appropriate adjustments. They finalize their objectives for the PI, to which the 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 customers, the team brings their program 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.
Program Risks. During planning, teams have identified critical program-level risks and impediments that could affect their ability to meet their objectives. These are addressed in a broader management context in front of the whole group. One by one, risks are categorized into one of the following groups 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, but someone takes ownership
- Accepted – Some risks are just 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 program PI objectives. Each team conducts a “fist of five” vote. If the average is three or four fingers, then management should accept the commitment. If the average is fewer than three fingers, then planning adjustments are made and plans are reworked. Any person voting two fingers or fewer should be given an opportunity to voice their concern. This might add to the list of risks, require some replanning, or simply be informative.
Plan Rework if Necessary. If necessary, teams rework their plans until a high confidence level can be reached. This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.
Planning Retrospective and 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 tools, scheduling upcoming key activities and events … and cleaning up the room!
Outputs of a Successful Event
A successful event delivers three primary artifacts:
1. A set of “SMART” objectives for each team, created by the team, with business value 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 ART execution (reliably delivering on cadence requires capacity margin). Figure 3 shows a sample of one team’s PI objectives.
2. A “program board,” which highlights the new feature delivery dates, dependencies among teams and with other ARTs, and relevant milestones, as illustrated in Figure 4.
3. A vote of confidence/commitment from the entire ART to these objectives
Teams leave the event with a pre-populated backlog for the upcoming PI. This serves as fresh input into the normal Iteration Planning processes that follow.
After the meeting, the RTE synthesizes the team PI objectives into program PI objectives (see PI Objectives for more information) and uses this to communicate expectations to stakeholders and to track progress toward the goal. This usually happens after and not during the PI planning meeting. The program board may or may not be maintained after that time. Given the PI plan, the roadmap is typically updated by product management.
Finally, and most important, the program proceeds to execute the PI, tracking progress and adjusting as necessary to changes that occur as new knowledge emerges.
PI Planning in Multi-ART Value Streams
The above description focuses on the planning activities of a single ART. However, in larger value streams, multiple ARTs conduct such planning sessions and cross-ART coordination is also required. Based on logistics, geography, and scope, these may be done contemporaneously, or they may be staggered over a few days in the Innovation and Planning Iteration. In this case the PI planning events are bracketed in time by value stream-level pre- and post-PI planning events.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 16.
 Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
Last update: 20 April 2016