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.

—Authors

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 shared mission and Vision.

PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.

Details

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.

Where possible this involves physical collocation, and these large scale PI planning events now take place within many enterprises around the world. They have clearly shown real financial ROI, not to mention the intangibles that occur when the team of Agile teams creates a social construct that is personally and collectively rewarding.

It may not always be practical for the entire Agile Release Train (ART) to collocate however, and in our current times COVID-19 has created a situation where this isn’t an option. While physical face to face planning has its benefits, the unwritten SAFe ‘rule’ is “the people who do the work plan the work.” When physical presence is not possible, real time, concurrent, virtual, face to face planning has now proven to be effective. Indeed many ARTs have been successful in creating a hybrid situation where several teams join remotely, as shown below in Figure 1.

The advanced topic article, Distributed PI Planning with SAFe, provides additional guidance and considerations for successfully managing these scenarios.

PI Planning has 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 Program Increment (PI). Facilitated by the Release Train Engineer (RTE), this event includes all members of the ART 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 takes place over two days, although this is often extended to accommodate planning across multiple time zones.

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 and 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 – Highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones.

Preparation

PI planning is a significant event that requires preparation, coordination, and communication. It is facilitated by the RTE and event attendees include Business Owners, Product Management, Agile Teams, System and Solution Architects/Engineering, the System Team, and other stakeholders, all of whom 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
• Logistics readiness – Considerations for running a successful event

Below are highlights of the ART Readiness Checklist. (The full checklist is provided in the SAFe PI Planning Toolkit, available to SPCs).

Organizational Readiness

Before PI planning, there must be 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 team members and an identified Scrum Master and Product Owner for each team?

Content Readiness

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

Logistics Readiness

Preparing an event to support a large number of attendees isn’t trivial. For physically collocated planning this can include securing and preparing the physical space. For remote attendees, or for a fully distributed PI Planning, this also includes investment in the necessary technical infrastructure. Considerations include:

• Locations – Each planning location must be prepared in advance
• Technology and tooling – Real-time access to information and tooling to support distributed planning or remote attendees
• Communication channels – Primary and secondary audio, video, and presentation channels must be available

Standard Agenda

The event follows an agenda similar to Figure 2. Descriptions of each item follow. For guidance on adapting this agenda to support planning across multiple time zones, refer to the advanced topic article, Distributed PI Planning with SAFe.

Day 1 Agenda

• Business context – A Business Owner or senior executive describes the current state of the business, shares the Portfolio Vision, and presents a perspective on how effectively existing solutions are addressing current customer needs.
• Product/solution vision – Product Management presents the current vision (typically represented by the next top 10 upcoming features) and highlights any changes from the previous PI planning event, 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 RTE presents the planning process and expected outcomes.
• Team breakouts #1 – In the breakout, teams estimate their capacity 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 ‘uncommitted 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. Uncommitted 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 teams also add the features and associated dependencies to the program board, as shown in Figure 3.

• Draft plan review – During the tightly timeboxed draft plan review, teams present key planning outputs, which include capacity and load, draft PI 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 event may be held after the first day of planning to resolve 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 each ART’s specific management review and problem-solving meeting. The Solution Train Engineer (STE) helps facilitate and resolve issues across the ARTs.

Day 2 Agenda

• Planning adjustments – The next day, the event begins with management presenting any changes to planning scope, people, 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 and provides the risks to the RTE for use later in the ROAMing exercise. The team then asks the Business Owners if the plan is acceptable. If the plan is accepted the team brings their team PI objective sheet to the front of the room so everyone can see the aggregate objectives unfold in real-time. If the Business Owners have concerns, teams are given the opportunity to adjust the plan as needed to address the issues identified. The team then presents their revised plan.
• Program risks – During planning, teams have identified program 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 discussed and addressed with honesty and transparency, and then categorized into one of the following categories:
  • Resolved – The teams agree that the risk is no longer a concern.
  • Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
  • Accepted – Some risks are just facts or potential problems that must be understood and accepted.
  • Mitigated – Teams identify a plan to reduce the impact of the risk.
• Confidence vote – Once program risks have been addressed, teams vote on their confidence in meeting their team PI objectives.

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 concerns. This might add to the list of risks, require some re-planning, or simply be informative. Once each team has voted the process is repeated for the entire ART with everyone expressing their confidence in the collective plan, as illustrated in Figure 5.

• 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 stories in an Agile project management tool.
  • Reviewing team and ART events calendars.
  • Determining Iteration Planning and daily stand-up (DSU) locations and timings.

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 to track dependencies. It may, or may not, be maintained (manually) after planning is complete. 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 ART 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 created during PI Planning did not take into account detailed story level 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 event, which sets the context and provides the inputs for the individual ART PI planning events. A Post-PI Planning event follows 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 accommodating Pre- and Post-PI planning events.

 

---

Learn More

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

[2] Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.

Last update: 10 February 2021