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.
Program Increment (PI) planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a common mission and vision.
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 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. Here, the teams create their iterations 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. The result of planning is a commitment to an agreed set of Program PI objectives for the next PI. Holding the event during the IP iteration avoids affecting the timebox, scheduling, or capacity of other iterations in the PI.
PI Planning is integral and 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/ cross-ART collaboration
- Providing the opportunity for “just the right amount” of Architecture and User Experience (UX) guidance
- Matching demand to capacity, eliminating excess Work in Process (WIP)
- Fast decision-making
Below are descriptive highlights from the ART Readiness Checklist in . For additional details, see Figures 17-3 and 17-4 in Chapter 17 of .
Input and Outputs of PI Planning
Inputs to PI planning include:
- Business context (see Content Readiness below)
- Roadmap and vision
- Top 10 features from 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 set by the Business Owners. Each objective is written in such a way that it is:
- Specific – expresses the intended outcome as simply, concisely, and explicitly as possible. (Hint: Try starting with an action verb.)
- Measurable – measures should be stated to clarify what the team needs to do to meet the objective. It may be descriptive, yes/no, quantitative, or provide a range.
- Achievable – achieving the objective should be within the team’s control and influence.
- Realistic – recognize factors that cannot be controlled. (Hint: Avoid making “happy path” assumptions.)
- Time-bound – the time period for achievement must be within the PI, and therefore all objectives must be scoped appropriately.
- Program Board – the planning board highlights the new feature delivery dates, feature dependencies among teams and with other ARTs, and relevant milestones.
PI planning is a major event that requires preparation, coordination, and communication. 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.
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
Below are descriptive highlights from the ART Readiness Checklist in . For additional details, see 17-3 and 17-4 in Chapter 17 of .
Prior to planning, it’s important to ensure that Programs have reasonable 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? Does each have dedicated developer and test resources and an identified Scrum Master and Product Owner?
It’s equally important to ensure that there is 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 ten Features in the Program Backlog
- Architecture vision briefing – a briefing prepared by the CTO, Enterprise Architect, and/or System Architect to communicate new Enablers, features, and Non-functional Requirements (NFRs)
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 itself.
- Communication channels – For distributed planning meetings, primary and secondary audio, video, and presentation channels must be available.
The meeting generally follows a standard agenda similar to Figure 2. Descriptions of each agenda 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 current 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 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, 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. Rather, they increase the reliability of the plan and give management an early warning of objectives 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, 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 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 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 period. 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, the risks are addressed clearly, honestly, and visibly, and then categorized in the following groups:
- 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, as illustrated in Figure 5.
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 re-planning, 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 iteration planning meeting locations
After the planning event is done, the RTE and other ART stakeholder 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 Scum 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 pre-populated 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 normal Iteration Planning processes that follow. Since the iteration plans did not take into account the story acceptance criteria, it’s likely that adjustments will be need to be made to the first and subsequent iteration plans.
PI Planning for a Solution Train
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.
An example calendar showing the timing for the Pre- and Post- PI planning meetings is shown in Figure 1 in the Innovation and Planning iteration article.
Learn More 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: 14 June April, 2017