7. Planning a Program Increment
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
Preparation for the PI Planning Event
Day 1—Create and Review Draft Plans
Day 2—Finalize Plans and Commit
Overview
There is no magic in SAFe ... except maybe for PI planning.
—The authors
There is no other, more powerful event like PI planning in the Scaled Agile Framework (SAFe). It is the cornerstone of the Program Increment (PI)—which provides the cadence, or rhythm, for the Agile Release Train (ART).
It’s amazing how much alignment and energy are created when there are 100 or so people all working together toward a common mission, vision, and shared purpose. Gaining that alignment in just two days can save weeks, if not months, of delays waiting on decisions, getting ahold of the right people, and coming to agreement via a flurry of emails.
More importantly, this event represents a critical and cultural milestone for the implementation of SAFe.
• This is the event where the teams come together periodically to better define and design the system that fulfills the vision and commit to near-term PI objectives.
• This is the event the ART uses to create, foster, and sustain a sense of shared mission, responsibility, cooperation, and collaboration.
• This is the event where the responsibility for planning moves from central authority to the teams who do the work. This sends a signal of true change from management that the teams are now empowered.
• This is the event that builds the social network that the ART depends on. After all, building large-scale, complex solutions is a social endeavor.
As shown in Figure 7-1, PI planning is a significant event, which occurs either face-to-face in a single location or in multiple face-to-face locations at the same time.
In Figure 7-1, there are teams in the United States planning at the same time with remote teams in India, using video conferencing. Leads from teams in Eastern Europe are attending the US event in person and are collaborating with their teams remotely. US-based Business Owners are sitting at the table in the middle, being accessible to everyone. Product Owners are with their teams in India.
Whenever possible, attendees include all members of the ART. After all, they are the ones doing the work, so they are the only ones who can design the system, plan, and then commit to the plan. Led by a facilitator (Release Train Engineer [RTE] or other), PI planning takes place over two days and occurs within the Innovation and Planning (IP) iteration. That prevents the planning meeting from affecting the PI timebox or the capacity of other iterations in the PI.
When value streams have multiple ARTs, pre- and post-PI planning meetings are held to coordinate across individual ART planning sessions. For more information, refer to chapter 12, “Coordinating ARTs and Suppliers.”
Preparation for the PI Planning Event
Such a significant event requires preparation, coordination, and communication. Product Management, Agile teams, System and Solution Architect/Engineering, the System Team, Business Owners, and other stakeholders must be well prepared.
Preparation for a successful event is required in three major areas:
1. Organizational readiness
2. Content readiness
3. Facility readiness
Organizational Readiness
Prior to planning, it’s important to ensure that programs have reasonable strategic alignment among participants, stakeholders, and Business Owners. In other words, they all must agree on exactly what they are building. To address this, preparedness questions include the following:
• Planning scope and context. Is the scope of the planning process—product, system, or technology domain—understood?
• Business alignment. Is there reasonable agreement on priorities among the Business Owners?
• Agile teams. Does each team have dedicated developer and test resources and an identified Scrum Master and Product Owner?
For more on organizational readiness, see chapter 17, “Implementing Agile Release Trains.”
Content Readiness
PI Planning starts with leadership providing shared vision and context. Presentation elements include the following:
• Executive briefing. A briefing by a senior executive or line-of-business owner, which defines the current business context.
• Product/solution vision briefing. Briefings prepared by Product Management, including the vision and top 10 features in the program backlog. To be ready, Product Managers develop acceptance criteria that can be used to establish that the feature meets its Definition of Done (DoD).
• The architecture vision briefing. The briefing prepared by the CTO, Enterprise Architect, and/or System Architect/Engineering communicates architectural strategy, as captured by new enablers and nonfunctional requirements.
Facility Readiness
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 the following:
• Facility. The planning venue must be large enough for all attendees. If there is not sufficient space for the teams to plan, breakout rooms—if close by—may be appropriate.
• Technical and communications support. Support people need to be identified and available during setup, testing, and the event itself.
• Communication channels. For distributed planning meetings, primary and secondary audio, video, and presentation channels must be available.
Role of the Facilitator
The PI planning event represents an alignment singularity—the point at which all must agree on what should and can be accomplished in the upcoming PI. As such, it can be a politically charged session, where stakeholders see the work physics of what they are asking for and teams objectively determine what they can do. Since imagination and market opportunity is largely unlimited, that means most ARTs are overloaded with expectations and excess Work in Process (WIP), which must be flushed out of the system. Bringing those expectations into alignment with reality can be a bit traumatic for many stakeholders. To this end, the importance of an effectively facilitated event cannot be understated. Someone has to run an objective process such that the facts are surfaced and addressed.
That responsibility falls to the role of the facilitator. The facilitator organizes and guides PI planning to ensure that the group’s objectives are met effectively, with good participation and full buy-in from everyone involved. The RTE may be a good candidate to be the facilitator. Often, they have experience as a program manager and may have the skills needed to plan and facilitate this type of event. In other cases, the RTE may bring in someone else to facilitate the event. This allows the RTE to focus on the teams and their needs and enables someone else to be committed to managing the timing and progress of the event, free of distraction and without a vested interest in the outcome.
The secret of good facilitation is an effective group process that flows—and with it flows the ART’s ideas, solutions, and decisions. An agreed-to agenda helps. Over time, SAFe has evolved a standardized agenda, which works in most contexts, as shown in Figure 7-2.
Day 1—Create and Review Draft Plans
Day 1 of the event begins with the facilitator reviewing the objectives and agenda, working agreements, planning rules and expectations, and other logistics. The facilitator also presents the upcoming calendar of events, including the iteration and release cadence, future PI planning dates, scheduled releases, holidays, milestones, or other events that may affect planning objectives or team capacity.
Business Context
Next, a senior executive or line-of-business owner provides the business context for the planning session. This may include the following:
• Discussions of current business performance and strategy
• Measures of customer satisfaction
• Organizational developments and updates to operating plans
• Strengths, Weaknesses, Opportunities, Threats (SWOT) analysis
This discussion sets the tone for the PI planning session and can drive the motivation and enthusiasm for the PI and the solution being developed. It’s a chance to share success stories, understand the market risks, and rally the troops around a set of challenges to overcome.
The presenter may conclude with an overview of strategic themes and business objectives for the upcoming periods.
Since this is an opportunity to align all development teams under a common vision, meeting organizers should reach as high into the organization as possible for this opening speaker. It also gives the teams a chance to meet and interact with a senior executive who drives the business vision.
Product/Solution Vision
Next, Product Management presents the current vision, the objectives for the upcoming PI, and feature priorities. If there are multiple product managers, each may need some time to present the vision and top features for their particular area of the solution.
Architecture Vision and Development Practices
In this session, the System Architect/Engineering presents the vision for the architecture. This may include descriptions of new architectural epics for common infrastructure, any large-scale refactors under consideration, and system-level Nonfunctional Requirements (NFRs).
In addition, as Agile puts extreme pressure on development practices and infrastructure, a technical leader usually guides the discussion about changes to standard development practices, and new tools and techniques for built-in quality practices for the Definition of Done (DoD).
Team Planning Breakouts
The next session is the longest and most critical of the event. At this point, the teams break out into separate meetings and draft their initial plan to achieve the objectives of the PI. In this session, the teams iterate through a process that proceeds roughly as follows:
• Meet with product managers and other stakeholders to better understand features and their priorities.
• Estimate the velocity the teams will have during each iteration.
• Brainstorm and identify all the stories needed to meet the input objectives and prioritized features of the PI. (Note: There’s no time for story elaboration or acceptance criteria. Too much detail bogs down the process and creates false precision and excessive WIP.)
• Understand the impact of architectural initiatives on the plan, and identify stories for those initiatives as well.
• Incorporate improvement backlog items that came out of previous team retrospectives and the PI’s Inspect and Adapt (I&A).
• Identify dependencies within the team and on other teams.
• Estimate the stories and place them on iterations in order until capacity is exhausted.
• Capture a backlog of things that can’t be accomplished in the time period and will have to be postponed.
During this process, teams will consult with Product Managers, System Architect/Engineering, the System Team, User Experience, and other teams. Their goal is to understand the scope and priorities necessary for infrastructure development, resolve dependencies, and understand the potential for reuse of common code. It’s an intense and active time.
Plans are created using flipchart paper and story cards (or stickies) so that they’re visible for all to see. Teams create one sheet per iteration, another for team PI objectives, and one to capture program risks and impediments. A standard plan might appear as shown in Figure 7-3.
Note that the IP iteration should not contain any user stories, even though the teams may identify other stories dedicated to such specialty tasks as load and performance testing, system documentation, and other activities.
As shown in Figure 7-4, teams use color-coded sticky notes to provide visibility into the number of backlog items dedicated to certain activity types, such as user stories, maintenance, and enablers.
Starting Fast with Capacity-Based Planning
In the first PI planning session, many teams will not have used Scrum in the past and will, therefore, not have a starting velocity to plan with. In this case, teams simply start with eight points per iteration for each full-time technical contributor. They then identify a story that will take about one day of work, and estimate it at one story point. Other stories are estimated relative to that one. Teams split any story larger than eight points.
This accomplishes two things.
1. Assures that most teams have a reasonable number of right-sized stories in an iteration
2. Normalizes estimation across teams. This is important for feature and epic-level estimating and for conversion into cost estimates where necessary
Note: If teams already have velocities, a quick check will probably discover that they are already mostly normalized. Small teams will have about 30, really big teams 50–60. If this is not the case, the facilitator may want to have some teams adjust accordingly so that program velocities make sense. While there may be some emotion around the adjustment, just remind the teams that they are unit-less numbers, so there can be no harm in making an adjustment to make it easier to manage the economics of the program.
Hourly Planning Checkpoints
During the team breakouts, the facilitator holds an hourly Scrum of Scrums (SoS) checkpoint to keep the planning on track. In this short stand-up meeting, the RTE and the Scrum Masters from each team meet to review planning status using a checklist. Figure 7-5 shows an example. The SoS is often followed by a “meet after” for any problems that need more discussion.
Draft Plan Review
At the designated time, the group reconvenes in the plenary session to review each of the plans. Many plans will be incomplete. However, the review is still held on time so that the groups can see the planning process and take an initial look at the assumptions, dependencies, and objectives that their counterpart teams are working on. Each team presentation is strictly timeboxed at five to ten minutes per team, based on the size of the ART. Business Owners should be present throughout.
In addition, other executives, managers, and key stakeholders in the company may be invited to this portion of the event. This allows program visibility and a shared business and development context. Managers may have input or adjustments to the plan based on their contribution and perspective. In turn, the development teams may also have dependencies on these functions, for example, marketing, sales, customers, distribution, deployment, and IT.
Each team presents using the agenda shown in Figure 7-6.
Typically, there will be a few minutes left for Questions and Answers (Q&A), in which the facilitator has to walk the line between abruptly cutting off important discussions about dependencies, trade-offs, and misunderstandings to keep the sessions within the allotted timebox.
The session proceeds until all teams have presented their draft plans, even at the risk of exceeding the time allocated. For most attendees, this is the end of day 2.
Management Review and Problem-Solving Meeting
Some attendees, however, remain for additional, important work. Specifically, management and some team leads meet to make adjustments to scope and objectives based on the first day of planning. It’s likely that there will be far more work than the teams can possibly accomplish in the PI timebox. Many programs are over-scoped by 50–100 percent, and that will be obvious now. Resource constraints, bottlenecks, excessive dependencies, and team dynamics may also pose problems.
If these issues are allowed to persist into the second day, day 2 may come out badly for one of these two reasons:
1. The process will not converge on agreed-to PI objectives because of these unresolved issues.
2. Convergence will appear to happen, but the PI is at great risk because real, underlying problems have not been addressed.
To this end, some set of managers, Business Owners, Product Managers, System Architects/Engineers, Product Owners, and Scrum Masters must meet to address the larger challenges identified in the draft review session. Figure 7-7 shows some common questions asked by the facilitator.
The facilitator keeps key stakeholders together as long as necessary to make the decisions needed to increase the likelihood of a successful PI. Resolving these issues may involve cuts to scope, rethinking prior commitments and accepting that some critical milestones will not be met. It may become necessary to rethink team assignments or move entire features from one team to another. Any final decisions should be carefully and clearly summarized, as they will inform the next day’s planning session.
Day 2—Finalize Plans and Commit
In the opening session of day 2, the facilitator reviews the agenda and the objectives. Figure 7-8 shows a more detailed version of the day 2 agenda.
During day 2, the program must commit to a plan of action that fits the capacity of the teams, while delivering maximum value in the next PI timebox.
Planning Adjustments
Based on the previous day’s management review and problem-solving meeting, planning adjustments are discussed. Here are some examples:
• Changes to priorities
• Adjustments to plan and milestones
• Changes to scope
• Movement of people or teams
A senior manager (or perhaps the management team as a group) takes responsibility for describing the issues and planning adjustments that were agreed to during the review meeting at the end of day 1.
Team Breakouts Continue
Based on the new knowledge (and a good night’s sleep), teams work to create their final plans.
• Teams finalize their iteration plans and PI objectives.
• Teams establish stretch objectives to provide the guard band (buffer) needed for predictability.
• Business Owners circulate and assign business value to PI objectives from low (one) to high (ten).
• Teams consolidate program risks, impediments, and dependencies.
• Teams ensure that the program board (covered later in the chapter) is updated with all features and cross-team dependencies.
And, as with day 1, the planning SoS convenes hourly to ensure that the teams and plans are ready for the final review.
Team PI Objectives
Toward the end of the planning session, the teams will be focused on negotiating the final PI objectives with Product Management and Business Owners.
Team PI objectives are brief summaries of what the teams are prepared to commit to during the PI, expressed in business terms. Many of the objectives will be based on features from the backlog, which were described in the day 1 vision briefing. Others, however, may represent infrastructure or architectural objectives the team must achieve. Still others may be a summary of a set of features, milestones, releases, or even less tangible items that remain worthy of notice and attention at this top-level output of the PI planning process.
“SAFe’s use of PI objectives provides a unique tool to create an immediate feedback loop from the teams back to the business owners, allowing a quick validation of the teams’ grasp of the desired outcomes. In short, we give the teams the following challenge:
“Can you concisely convey, in words the business owner understands, the essence of the value sought by implementing this set of features?”
“By asking the teams to summarize the intent and the outcomes they believe the business owner wants to achieve, we close the loop of understanding and drive crucial conversations that expose these misunderstandings. This in turn enables a much tighter form of alignment that transcends the written language of the feature to be amplified by the tacit understanding gained between the team and the business owner.”1
1. Eric Willeke, “The Role of PI Objectives,” http://dev.scaledagileframework.com/the-role-of-pi-objectives/
Stretch Objectives
The goal of the entire session is to commit to a near-term set of objectives. But gaining a meaningful commitment can be tricky. It’s R&D after all. But without it, the business can’t plan, even for the short term.
Applying “stretch objectives” helps immensely by providing a guard band for the reliability of the PI. These objectives are included in the planning process (that is, stories have been defined and included in the plan for these objectives), but the stretch objectives are not included in the PI commitment. They also give management an early warning of objectives that the ART may not be able to deliver. The expectation is that teams will meet most of their committed objectives. This gives teams the flexibility they need to commit to a subset of the planned objectives, without too much risk in the total scope of the work.
And one must constantly keep in mind that stretch objectives are used to identify what can be variable within the scope of a plan. Stretch objectives are not the way for stakeholders to load the teams with more work than they can possibly do. It’s simply used to identify objectives that the teams can’t commit to because there is too much risk or uncertainty.
Establish Business Value
The primary evaluation tool of the ART is a predictability measure that tracks the percent of business value achieved for each PI objective in the plan. To execute this, the business value of each objective is set by the Business Owners toward the end of the PI planning session, as shown in Figure 7-9.
Naturally, not all objectives deliver equal value, and Business Owners are likely to assign higher numbers on externally visible objectives than they would on infrastructure accomplishments and architectural epics. That’s as it should be. And yet, mature Business Owners know that these technical concerns will also increase the velocity of the teams in producing future business value. So, placing some business value on those items shows maturity and support for the teams.
As the road after PI planning takes its inevitable twists and turns, having objectives ranked by business value guides the teams to make trade-offs and minor scope adjustments in ways that deliver the maximum business value.
Program Board
Typically, a program board is created by the RTE in advance of planning and is updated by the teams during planning. The board highlights the feature delivery dates, milestones, and dependencies among teams and with other ARTs, as shown in Figure 7-10.
Final Plan Review
This is a repeat of the review session from the day before, but by now, the teams will have completed their plans.
• All iterations are planned (except for the IP iteration). Work fits into the time available.
• Out-of-scope work has been identified on a backlog sheet.
• Business Owners/Product Managers have reviewed and agreed to plan and objectives.
• Teams have a final set of PI objectives (including stretch) with business value assigned by Business Owners.
• Teams have also identified all critical dates and have updated the program board with milestones and features.
• Teams have identified the key risks and impediments outside of their local control but have the potential to cause the team to fail to meet the objectives.
Figure 7-11 shows a sample agenda for the final walk-through.
During each team’s presentation, the facilitator is looking for agreement within and across the teams, as well as among the Business Owners, on the feasibility and appropriateness of the plan. Questions from reviewers are asked and answered.
At the end of each team’s time slot, each team states their remaining risks and impediments. But there is no attempt to resolve them in this brief period. If the plan is acceptable to the Business Owners, the team brings their team PI objective sheet and remaining program risks sheet to the front of the room. This allows everyone to see the summary of PI objectives unfold in real time. This process continues until all teams have presented their plans.
Addressing Program Risks and Impediments
Even though the plans are now complete, there is still work to do. During the planning, teams were asked to identify the most critical program risks and impediments—the very issues that could affect their ability to meet their agreed-to objectives. Addressing them is critical, as they typically represent things that—left unaddressed—may interfere with the success of the next PI.
ROAMing the Risks
By now, the teams will have addressed the risks that are under their local control. Otherwise, they couldn’t be responsible for their own plan. The remaining risks and impediments will need to be addressed in a broader, management context. To that end, every program-level risk identified by the team will be addressed in front of the full group. Each item is discussed until it can be categorized in one of the following ROAM categories:
• Resolved. If, after discussion, the teams agree that an issue is no longer a material concern, it moves to resolved.
• Owned. If an item cannot be resolved in the course of the meeting, someone takes ownership. The item is then moved to the owned sheet, where its owner is recorded.
• Accepted. Some risks or impediments are potential occurrences (for example, a delayed vendor delivery, excessive emergency maintenance requirements) that must simply be acknowledged and accepted. If these actually occur, then the ART will likely not meet all elements of the commitment.
• Mitigated. Often, the teams can develop a plan to mitigate the impact of a risk item such that it should not materially impact the outcome. If so, a mitigation plan is identified.
The Commitment
After all risks have been moved to a ROAM category, the “backlog of risks and impediments” sheet is empty. The PI objectives are apparent and visible in the front of the group.
Now is the time to ask to ask the teams how confident they are that they will be able to meet the objectives of this PI. The teams vote using a “fist of five,” where each finger represents a level of confidence.
1. No confidence; will not happen
2. Little confidence; probably will not happen
3. Good confidence; the team should be able to meet the objectives
4. High confidence; should happen
5. Very high confidence; will happen
If the average is three or more fingers, management should accept the commitment and move forward. If the average is less than three fingers, then there’s still work to do. Scope and resources must be adjusted again, and planning continues—that day, into the evening, or even rolling over into the next morning—until a commitment is reached. At this point, alignment and commitment are more valuable than strict adherence to a timebox.
A Commitment in Two Parts
Achieving a reasonable commitment in the face of so many unknowns, some of which are outside the control of the teams, is not a trivial thing. After all, there is inherent risk and uncertainty in research and development. Leadership must create a culture wherein risk-taking and commitment are both part of the norm. Given this context, when teams do their confidence vote, all can interpret that as a commitment, but this commitment has two parts.
1. Teams commit to do everything reasonable to meet the agreed-to objectives.
2. In the event that, over time, facts change or new learning occurs that indicates that achieving the committed objectives is no longer achievable, teams agree to escalate immediately so that management is informed and corrective action can be taken.
In this way, teams know that they can and should take reasonable risks and also commit to an outcome, knowing that management understands and appreciates the risks and is fully supportive of the trust, transparency, and integrity that this model engenders.
Planning Retrospective
The next session is a brief retrospective of the PI planning session led by the facilitator. Figure 7-12 shows a simple format to capture the results, along with a few example comments.
This session should last no longer than 15–20 minutes. Near the end of that timebox, the facilitator may ask the teams to rank the items in the third column (what we could do better next time) to focus on process improvements that can be taken before the next planning session.
Moving Forward and Final Instructions to Teams
The last session is typically a discussion about the next steps, along with final instructions to the teams. This might include the following:
• Capturing the team PI objectives and user stories in the Agile project management tool
• Reviewing team and program calendars
• Reviewing iteration planning meeting locations
After planning is done, the RTE summarizes the individual team PI objectives into a set of program PI objectives.
Summary
This chapter provided an overview of the PI planning process, which is a cadence-based, face-to-face planning event that serves as the heartbeat of the ART. It is integral and essential to SAFe.
The key takeaways from this chapter are as follows:
• Preparation for a successful PI planning event is required in three major areas: organizational readiness, content readiness, and facility readiness.
• PI planning delivers many business benefits, which include establishing face-to-face communication, aligning development to the business and architectural vision, identifying dependencies, matching demand to capacity, and accelerating decision-making.
• The facilitator, often the RTE, organizes and guides PI planning to ensure that the ART’s objectives are met effectively, with clear thinking, good participation, and full buy-in from everyone.
• The first day of planning includes establishing the business context and planning requirements, creating draft plans, and concluding with a management review and problem-solving meeting.
• The second day of planning includes discussion of planning adjustments, finalizing plans and establishing business value, ROAMing the risks, approving the final plan and committing to the PI objectives to end the session.
• The key outputs of PI planning are a program board, which highlights the feature delivery dates, milestones, and dependencies, and PI plans and a committed set of PI objectives.