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

There is no magic in SAFe . . . except maybe for PI Planning.

—Authors

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. For geographically distributed ARTs, this planning event may occur at multiple locations simultaneously by maintaining constant audio and video communication between the sites.

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—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.

Figure 1. Face-to-face PI planning. Remote teams are planning at the same time using video conferencing (Image courtesy of Scaled Agile, Inc.)

Business Benefits of PI Planning

PI planning delivers many business benefits:

• Establishes face-to-face communication across all team members and stakeholders

• Builds the social network on which the ART depends

• Aligns development to business goals with the business context, Vision, and Team and Program PI objectives

• Identifies dependencies and fosters cross-team and cross-ART collaboration

• Provides the opportunity for ‘just the right amount’ of architecture and Lean User Experience (UX) guidance

• Matches demand to capacity, eliminating excess Work in Process (WIP)

• Facilitates fast decision-making

Following are highlights of the ART Readiness Checklist [1].

Inputs and Outputs of PI Planning

Inputs to PI planning include the following items:

• Business context (see the ‘Content Readiness’ section)

• Roadmap and vision

• Top 10 Features of the Program Backlog

A successful PI planning event delivers two primary outputs:

• Committed PI objectives – This set of SMART objectives is created by each team, with the business value being assigned by the Business Owners.

• Program board – This board highlights the new feature delivery dates, feature dependencies among teams and with other ARTs, and relevant Milestones.

Preparation

PI planning is a significant 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 so that they can be well prepared.

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

• Organizational readiness – Strategic alignment and setup of teams and trains

• Content readiness – Management and development preparedness

• Facility readiness – The actual space and logistics for the event

Organizational Readiness

Before planning, Programs must have strategy alignment among participants, stakeholders, and Business Owners. Critical roles should also be assigned. To address these issues in advance, event organizers must answer the following questions:

• 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?

Content Readiness

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 these elements:

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

Facility Readiness

Securing the physical space and technical infrastructure necessary to support a large number of attendees isn’t a trivial matter—especially if there are remote participants. Considerations include the following elements:

• Facility – The facility must be roomy enough to accommodate all attendees, with breakout rooms if necessary.

• Facilities/tech support – These people need to be identified in advance and reachable during setup and testing, as well as during the event itself.

• Communication channels – For distributed planning meetings, primary and secondary audio, video, and presentation channels must be available.

Standard Agenda

The meeting follows an agenda similar to that shown in Figure 2. Descriptions of each item follow.

Day 1 agenda consists of seven blocks labeled as follows: business context (8:00 – 9:00), product/solution vision (9:00 – 10:30), architecture vision and development practices (10:30 – 11:30), planning context and lunch (11:30 – 1:00), (team breakouts) 1:00 – 4:00, draft plan review (4:00 – 5:00), and management review and problem solving (5:00 – 6:00). Day 2 agenda consists of seven blocks labeled as follows: planning adjustments (8:00 – 9:00), team breakouts (9:00 – 11:00), final plan review and lunch (11:00 – 1:00), program risks (1:00 – 2:00), confidence vote (2:00 – 2:15), plan rework? (2:15 - ???), and planning retrospective and moving forward.

Figure 2. Standard two-day PI planning agenda

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 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 its draft plans, which are made 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 not committed to by the team because of too many unknowns or risks.

Stretch objectives are not extra things to do in case the team has extra 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.

The column headers read, Iteration 1.1, Iteration 1.2, Iteration 1.3, Iteration 1.4, Iteration 1.5 (IP), and PI 2 >>>. The row headers read, Milestones/Events, Unicorns, Dolphins, Bears, Eagles, Iguanas, Antelope, Tarantulas, Needs UX Help, and Needs Sys Arch Help. The following cells show a blue rectangle: (2,3), (3,1), (3, 2), (4, 2), (4, 4), (5, 3), (5, 4), (6, 3), (7, 2), (7, 4), (8, 1), (8, 3), and (8, 4). The cell (2, 4) shows two blue rectangles. The following cells show a red rectangle: (3, 2), (3, 3), (3, 4), (4, 1), (4, 3), (6, 1), (6, 2), (6, 3), (9, 1), (9, 2), (9, 3), (10, 1), (10, 2), and (10, 3). The cell (1,3) shows an orange rectangle. The following rectangles in cells are connected by a red string: (1, 3) and (2, 3); (2, 3) and (3, 2) (red rectangle); (2, 4) (one of the blue rectangle) and (4, 3); (2, 4) (one of the blue rectangle) and (3, 4); (3, 2) (red rectangle) and (4, 1); (3, 2) (red rectangle) and (6, 1); (3, 2) (red rectangle) and (9, 1); (3, 2) (blue rectangle) and (6, 2); (3, 3) and (9, 2); (3, 3) and (6, 3); (3, 4) and (9, 3); (4, 3) and (10, 2); (6, 2) and (10, 1); and (7, 4) and (10, 3); Blue represents features, red or pink represents significant dependency, orange represents milestone or event, and red string represents a dependency requiring stories or other dependencies to be completed before the feature can be completed. A note pointing to the cell (1, 3) reads, a program milestone or event is happening in iteration 1.3 (example – a trade show, market release, etc.). A note pointing to the cell (2, 3) reads, this feature cannot be delivered until multiple teams complete their dependencies. A note pointing to the cell (4, 2) reads, a feature placed in a team’s swim lane with no strings means that it can be completed independently of other teams.

Figure 3. 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’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.

  

  The PI objectives along with business values are as follows: proof of concept with mock sounds (10), help with radar POC (4), and decide to create or buy engine noises (3). Stretch objectives are as follows: proof of concept with real sounds (7).

  Figure 4. A team’s PI objectives sheet with assigned business values

• 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 its 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 its program PI objectives sheet and program risks sheet to the front of the room so that all can see the aggregate objectives unfold in real time.

• Program risks – During planning, teams will have identified program-level risks and impediments that could impact their ability to meet their objectives. These potential problems 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 identify a plan to reduce the impact of an item.

• Confidence vote – Once program risks have been addressed, teams vote on their level of confidence in their ability to meet their program PI objectives (Figure 5).

  

  Figure 5. Confidence vote for an ART (Image courtesy of Scaled Agile, Inc.)

  Each team conducts a ‘fist of five’ vote. If the average is three fingers or more, then management accepts the commitment. If this average is less than three, the team reworks the plan. Any person voting two fingers or fewer should be given an opportunity to voice his or her concerns. This might add to the list of risks, require some additional planning, or simply be informative.

• Plan rework – If necessary, teams rework their plans until they reach a high confidence level regarding their ability to meet the objectives. 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 (Figure 6).

  

  The board is partitioned into three sections. The first section titled “what went well” shows the following points: risk management, participation, all teams together, vision first, big undertaking, and program view. The second section titled “what didn’t” shows the following points: estimation was difficult in some cases, run out of food, and no vendor participation. The third section is titled “do better.”

  Figure 6. Planning retrospective (Image courtesy of Scaled Agile, Inc.)

• Typically, a discussion about the next steps, along with final instructions to the teams, follows. This might include the following actions:

  - 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 complete, the RTE and other ART stakeholders summarize the individual team PI objectives into a set of program PI objectives (Figure 7) and use this summary to communicate externally about the teams’ plans and to track progress toward the goals.

The program PI objectives are as follows: deliver basic search, sort, and view of books in inventory; deliver basic shopping cart, purchase and shipping options; and support investor demo by start of iteration 3. Team PI objectives show four notes titled, team A, team B, team C, and team D. Arrows from the teams points to program PI objectives. The objectives of team A along with business values are as follows: one-click search for books by title, author and genre (10); support investor demo by start of iteration 3 (9); and drag and drop columns by attribute (3). The objectives of team B along with business values are as follows: purchase books via various credit card types (10); allow customers to choose their optimal shipping option (8); and support investor demo by start of iteration 3 (9). The objectives of team C along with business values are as follows: allow users to comment on books they have purchased (8); support investor demo by start of iteration 3 (9); and implement type-ahead using index from search (3).The objectives of team D along with business values are as follows: provide book detail to web users (10), allow registered users to manage their profile (8), and support investor demo by start of iteration 3 (9).

Figure 7. Summarizing team PI objectives into a set of program PI objectives

Product Management uses the program PI objectives to update the roadmap and to 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. In other cases, it may not be maintained (manually) after the PI planning event. 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 that 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. These plans serve as 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 be needed to the first and subsequent iteration plans.

Solution Train PI Planning

This chapter focuses on the planning activities of a single ART. However, large Value Streams may include multiple ARTs and suppliers. In this case, the Solution Train provides coordination via 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 (as shown in Figure 8).

The figure shows six rightward arrows and a dashed horizontal line above the arrows labeled “large solution level.” Two agile release train overlaps the arrows. A horizontal bar labeled “supplier” is shown below the ARTs. ARTs and supplier are enclosed within a box labeled “solution train.” A vertical bar with ‘I ampersand A’ written over it intersects the ARTs and supplier. The intersection points show a block labeled “ART PI planning.” A downward arrow labeled “pre” points to the blocks. An upward arrow labeled “post” is emerging from the blocks.

Figure 8. PI planning with pre- and post- planning

The Innovation and Planning Iteration chapter provides an example calendar for the pre- and post-PI planning meetings.

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.