PI Planning

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 [1]

Definition: PI Planning is a cadence-based event for the entire ART that aligns teams and stakeholders to a shared mission and vision.

What is PI Planning?

PI Planning is a cadenced event used for an Agile Release Train (ART) to align Agile Teams and ART leadership to a shared mission, vision, and committed plan. PI planning is essential in SAFe.

PI planning delivers many business benefits, including:

• Establishing face-to-face communication among all Agile Team members and stakeholders
• Aligning development to business goals with the business context, vision, and Team and ART 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)
• Making fast decisions
• Creating a wholistic, transparent view of where and when value will be delivered

Where possible, everyone is physically together. It may not always be practical for the entire Agile Release Train (ART) to collocate. While physical face-to-face planning has benefits, the focus is that the people who do the work plan the work. Real-time, virtual, face-to-face planning has also proven effective when physical presence is not possible as long as all members of the ART are participating.

How does an ART prepare for PI Planning?

PI planning is a significant event that requires preparation, coordination, and communication. It is facilitated by the RTE. Event attendees include Business Owners, Product Management, all Agile Teams, System and Solution Architects, and other stakeholders. The RTE must schedule PI planning events far enough in advance to ensure attendance. The active participation of Business Owners in this event provides an essential guardrail on budgetary spending.

Inputs to PI planning include:

• Business context
• Roadmap and vision
• Highest priority Features of the ART Backlog

A successful PI planning event delivers two primary outputs:

• Committed PI objectives – Each team creates a set of PI objectives with a business value assigned by the Business Owners.
• ART planning board – Identifying new feature delivery dates, feature dependencies among teams, and relevant milestones

For the event to be successful, preparation is required in three major areas:

• Organizational readiness
• Content readiness
• Logistics readiness

The following sections describe these three areas.

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 planning process’s scope (product, system, technology domain) 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/Team Coach and Product Owner for each team?

Content readiness

It’s equally important to have a clear vision and context so that the right stakeholders can participate. Therefore, the PI planning must include the following:

• 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 ART Backlog
• Architecture vision briefing – A presentation made to communicate new enablers, features, current and future state architecture, and Nonfunctional Requirements (NFRs) related to the coming PI

Logistics readiness

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

• Locations – Each location where planning takes place needs preparation 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

This article focuses on the planning activities of a single ART. However, large value streams may contain multiple ARTs and suppliers. In this case, multiple PI Planning events may need coordination. Further information on how to coordinate at this scale is found in Pre-Planning and Coordinate and Deliver guidance articles.

How to run a PI Planning event?

PI Planning has a standard agenda that begins with a presentation of the business context and vision. This is followed by team breakouts—where the teams create high-level iteration plans and committed objectives for the upcoming 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.

PI Planning occurs in a special iteration timebox called the IP Iteration. This avoids affecting the capacity of other iterations the Agile Teams are delivering within. PI Planning takes two days, although the ART can extend this timebox to accommodate planning across multiple time zones.

The event follows an agenda similar to Figure 1. Descriptions of each item follow.

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 address current customer needs.
• Product/solution vision – Product Management presents the current vision (typically represented by the top ten or so upcoming features). They highlight changes from the previous PI planning event and any relevant milestones.
• Architecture vision and development practices – The System Architect 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 the teams will adopt 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 (Figure 2). Each team creates 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 (for example, 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 any objectives that the ART may not be able to deliver. The teams also add the features and associated dependencies to the ART Planning 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 – Draft plans likely present challenges like 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.

Note: Solution Trains often hold an additional management review and problem-solving workshop after the first day of planning to address cross-ART issues. Alternatively, the RTEs of the involved trains may talk with each other to discuss the problems for the 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 changes to the planning scope, people, and resources.
• Team breakouts #2 – Teams continue planning and 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 – All teams present their plans to the group during this session. At the end of each team’s time slot, the team states its risks and impediments and provides the risks to the RTE for use later in the ROAMing exercise. Each Agile 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 can adjust the plan to address the identified issues. The team then presents its revised plan.
• ART PI Risks – During planning, teams have identified risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context before the whole train. One by one, the risks are discussed and addressed with honesty and transparency and then grouped into one of the following categories:
  • Resolved – The teams agree that the risk is no longer a concern
  • Owned – Someone on the ART owns the risk since it cannot be addressed during PI planning
  • Accepted – Some items are simply facts or potential problems that must be understood and accepted
  • Mitigated – Teams identify a plan to reduce the impact of the risk

• A confidence vote in two parts – To gauge readiness for the final plan review, each team conducts a voting mechanism called ‘fist of five’ physically or in a digital tool. This first vote often occurs during the last team breakout. Additionally, once ART PI risks have been addressed, the entire ART conducts a ‘fist of five’ physically or in a digital tool. If the average is three or above, then management should accept the commitment. If it’s less than three, the ART may need to rework its plan. Anyone voting two or fewer should be allowed to voice their concerns. These concerns might add to the risk list, require replanning, or provide information.

• Plan rework – If necessary, teams adjust their objectives until the ART has high confidence. This additional planning 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 to do better next time.

What happens after PI Planning?

Next steps – Typically, a discussion about the next steps, along with final instructions to the teams, follows, including:

• Cleaning up the rooms used for planning (if applicable)
• Entering the team PI objectives and stories in Agile lifecycle management (ALM) tooling
• Reviewing team and ART events calendars
• Determining Iteration Planning and Team Sync locations and timing

After the planning event, the RTE and other ART stakeholders summarize the individual team PI objectives into a set of ART PI objectives (Figure 6) and use this to communicate externally and track progress toward the goals.

Product Management refines the roadmap using the ART PI objectives, improving the forecast for the following PIs.

Teams leave the PI planning event with a prepopulated backlog for the upcoming PI. They take their team’s PI objectives, plans, and risks to their regular work area or update their digital tool to accurately reflect the plan. ART risks remain with the RTE, which ensures that the people responsible for owning or mitigating a risk have captured the information and are actively managing the risk. The ART Planning Board is maintained physically or digitally throughout the PI to enable dependency and milestone management.

Most importantly, the ART executes the PI, tracking progress and adjusting as necessary 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. It offers fresh input for the iteration planning processes that follow. Since the plans created during PI Planning did not consider detailed story-level acceptance criteria, the team will likely adjust the first and subsequent iteration plans.

---

References

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