Future product development tasks can’t be predetermined. 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.
Introduction to PI Planning: A Quick Overview
For geographically distributed ARTs, the event may occur at multiple locations simultaneously by maintaining constant audio and video communication between the sites.
The Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.”
SAFe takes this to the next level with PI planning, a routine, face-to-face event, with a standard agenda that includes a presentation of business context and vision followed by team planning breakouts—where the teams create their Iteration plans and objectives for the upcoming PI.
Facilitated by the Release Train Engineer (RTE), this event includes all members of the ART, whenever possible. It takes place over two days and occurs within the Innovation and Planning (IP) Iteration. Holding the event during the IP iteration avoids affecting the scheduling, or capacity of other iterations in the PI.
PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe. This is quite a significant occasion, as Figure 1 implies.
Business Benefits of PI Planning
PI planning delivers many business benefits, including:
- Establishing face-to-face communication across all team members and stakeholders
- Building the social network the ART depends upon
- Aligning development to business goals with the business context, Vision, and Team and Program PI objectives
- Identifying dependencies and fostering cross-team and cross-ART collaboration
- Providing the opportunity for ‘just the right amount’ of architecture and Lean User Experience (UX) guidance
- Matching demand to capacity, eliminating excess Work in Process (WIP)
- Fast decision-making
Inputs and Outputs of PI Planning
Inputs to PI planning include:
- Business context (see ‘content readiness’ below)
- Roadmap and vision
- Top 10 Features of the Program Backlog
A successful PI planning event delivers two primary outputs:
- Committed PI objectives – A set of SMART objectives that are created by each team with the business value assigned by the Business Owners.
- Program board – This highlights the new feature delivery dates, feature dependencies among teams and with other ARTs, and relevant Milestones.
PI planning is a significant event that requires preparation, coordination, and communication. It is facilitated by the Release Train Engineer (RTE). Event attendees include Business Owners, Product Management, Agile Teams, System and Solution Architect/Engineering, the System Team, and other stakeholders who must be notified in advance to be well prepared. The active participation of Business Owners in this event provides an important Guardrail on budgetary spend.
For the event to be successful, preparation 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
Before planning, Programs must have strategy alignment among participants, stakeholders, and Business Owners. Critical roles are assigned. To address this in advance, however, event organizers must consider the following:
- 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? Are there dedicated developer and test resources and an identified Scrum Master and Product Owner for the team?
It’s equally important to ensure that there are a clear vision and context and that the right stakeholders can participate. Therefore, the PI planning must include:
- Executive briefing – A briefing that defines the current business context
- Product vision briefing(s) – Briefings prepared by Product Management, including the top 10 features in the Program Backlog
- Architecture vision briefing – A presentation made by the CTO, Enterprise Architect, or System Architect to communicate new Enablers, features, and Nonfunctional Requirements (NFRs)
Securing the physical space and technical infrastructure necessary to support a 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 and testing, and the event itself
- Communication channels – For distributed planning meetings, primary and secondary audio, video, and presentation channels must be available
The meeting follows an agenda similar to Figure 2. Descriptions of each item follow.
Day 1 Agenda
- Business context – A senior executive/line-of-business owner describes the current state of the business and presents a perspective on how well existing solutions are addressing current Customer needs.
- Product/solution 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 forthcoming Milestones.
- Architecture vision and development practices – System Architect/Engineering presents the architecture vision. Also, a senior development manager may introduce Agile-supportive changes to development practices, such as test automation, DevOps, Continuous Integration, and Continuous Deployment, which are being advanced in the upcoming PI.
- Planning context and lunch – 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, teams identify risks and dependencies and draft their initial team PI objectives. The PI objectives typically include ‘stretch objectives,’ which are goals built into the plan (e.g., stories that have been defined and included for these objectives), but are not committed to by the team because of too many unknowns or risks. Stretch objectives are not extra things to do in case there is time. Instead, they increase the reliability of the plan and give management an early warning of goals that the ART may not be able to deliver. The team also adds the features to the program board, as shown in Figure 3.
- 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’s likely that the draft plans present challenges such as scope, people and resource constraints, and dependencies. During the problem-solving meeting, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments. The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.
In multi-ART Solution Trains, a similar meeting may be held after the first day of planning to solve cross-ART issues that have come up. Alternatively, the RTEs of the involved trains may talk with each other to raise issues that are then resolved in the ART’s management problem-solving meetings. The Solution Train Engineer (STE) helps facilitate and resolve issues across the ARTs.
Day 2 Agenda
- 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 agenda from the previous day, making the appropriate adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value, as shown in Figure 4.
- Final plan review and lunch – During this session, 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 timebox. 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 program-level risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context in front of the whole train. One by one, the risks are addressed with honesty and transparency, and then categorized into one of the following categories:
- Resolved – The teams agree that the issue is no longer a concern.
- Owned – Someone on the train takes ownership of the item since it cannot be resolved at the meeting.
- Accepted – Some risks are just facts or potential problems that must be understood and accepted.
- Mitigated – Teams can identify a plan to reduce the impact of an item.
- Confidence vote – Once program risks have been addressed, teams vote on their confidence in meeting their program PI objectives, as illustrated in Figure 5.
Each team conducts a ‘fist of five’ vote. If the average is three fingers or above, then management should accept the commitment. If it’s less than three, the team reworks the plan. 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, 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 retrospective for the PI planning event to capture what went well, what didn’t, and what can be done better next time, as shown in Figure 6.
- Typically a discussion about the next steps, along with final instructions to the teams, follows. This might include:
- Cleaning up the rooms used for planning.
- Capturing the team PI objectives and user stories in the Agile project management tool.
- Reviewing team and program calendars.
- Determining Daily stand-up (DSU) meeting times and locations.
- Reviewing the locations for the Iteration Planning meetings.
After the planning event is done, the RTE and other ART stakeholders summarize the individual team PI objectives into a set of program PI objectives (Figure 7) and use this to communicate externally and to track progress toward the goals.
Product Management uses the program PI objectives to update the roadmap and will improve the forecast for the next two PIs, based on what was just learned.
The program board is often used during the Scrum of Scrums meetings to track dependencies, or it may not be maintained (manually) after that time. This depends upon the Agile project management tooling in place and the needs of the ART.
Teams leave the PI planning event with a prepopulated iteration backlog for the upcoming PI. They take their team’s PI objectives, iteration plans, and risks back to their regular work area. Program risks remain with the RTE, who ensures that the people responsible for owning or mitigating a risk have captured the information and are actively managing the risk.
Most important, the program proceeds to execute the PI, tracking progress and adjusting as necessary to the changes that occur as new knowledge emerges. Execution of the PI begins with all the teams conducting planning for the first iteration, using their PI plans as a starting point. This is fresh input for the Iteration Planning processes that follow. Since the iteration plans did not take into account the story acceptance criteria, it’s likely that adjustments will need to be made to the first and subsequent iteration plans.
Solution Train PI Planning
This article focuses on the planning activities of a single ART. However, large Value Streams may contain multiple ARTs and suppliers. In this case, the Solution Train provides coordination using a Pre-PI Planning meeting, which sets the context and input objectives for the individual ART PI planning sessions. A Post-PI Planning session follows the ART PI planning and is used to integrate the planning results of the ARTs that contribute to the solution.
The Innovation and Planning Iteration article provides an example calendar for the Pre- and Post-PI planning meetings.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
Last update: 3 October 2018