10

PI Events

There are several key events that happen as part of the PI boundaries and that only occur once in a PI. PI Planning is the kick-off in the same way that Iteration Planning starts the iteration. The Inspect and Adapt (I&A) Event closes out the PI in the same way that the Iteration Review and Retrospective close out the iteration.

We will cover the following topics in the chapter:

• PI Planning
• The execution of PI Planning
• The I&A event

PI Planning

The PI Planning Event is one of the most important events for any organization executing SAFe®. It’s often said that if you aren’t doing PI Planning, you aren’t doing SAFe®. PI Planning is like Iteration Planning for the ART. It’s often referred to as the heartbeat and is pivotal in keeping the Train on the tracks and delivering the right work.

There is a lot of work and effort that goes into the execution of successful PI Planning. As a Coach, you will want to ensure that the Release Train Engineer (RTE) is preparing throughout the PI for the next PI Planning Event.

Traditionally, PI Planning was a face-to-face event that occurred every 8-12 weeks, with 10 being typical. However, since Covid-19, it may no longer be practical or feasible to hold planning face-to-face. When possible, we still encourage face-to-face planning, as it promotes team building and collaboration.

If face-to-face planning is not an option, ensure you have invested in technology that will support virtual, remote, or distributed PI Planning. This includes video conference equipment, shared workspaces, virtual boards, break-out spaces, applications designed to support PI Planning that can be integrated with Agile planning tools, and so on.

Story from the real world

I was working with an organization and when we learned that Covid-19 was going to force remote planning for the remainder of 2020 and into 2021, the organization was reluctant to invest in more tools. There was an impression that a virtual whiteboard and MS Teams were sufficient. As a Coach, I could see that the teams weren’t planning as effectively as they had been when we were face-to-face. The organization was hesitant to invest in more tools to support an event that occurred a couple of times a year.

We calculated the cost of a single face-to-face PI Planning Event compared to the cost of the tools being requested. The difference was significant and we determined that after two PI Planning Events, the cost of the tools would be offset. A new Covid-19 variant was identified and we were not going to be able to return as quickly as we had anticipated to face-to-face PI Planning. We made the decision to invest in better tools and started to see more effective planning and improved delivery.

We also discovered that PI Planning remotely, even with improved tools, took longer and the conversations that would naturally occur during lunches and breaks didn’t occur. This led to some missed dependencies, and we discovered we needed to be even more intentional in finding ways for those types of conversations to occur. We established “fireside chats” during PI Planning and had 1 member from each team go into a specific room; these small groups were able to share what was going on in their team rooms and some of the work they were planning, and were able to get to know individuals from other teams a little better. The team members loved it and took part in these same sessions several times throughout the PI Planning Event.

The RTE and PI Planning

Many people would say that PI Planning is what being an RTE is all about and that successful PI Planning is the measurement of a good RTE. While there is more to being an RTE than executing successful PI Planning Events, it is a critical part of the role.

The RTE sets the tone of PI Planning. The RTE should have lots of enthusiasm and excitement, as that gets absorbed by others in the room. How prepared the space is (whether virtual or physical) will also impact the success of the event. The attitude and demeanor of the RTE also set the tone. If the RTE is overly stressed or doesn’t handle the inevitable curveball well, then the ART tends to behave the same. To this end, as a Coach, supporting the RTE through this event is critical.

Preparing for PI Planning

RTEs should begin to prepare for the next PI Planning Event shortly after the previous event ends, early in the PI. In Appendix A, you will find an expanded checklist of items, as well as suggested dates for PI Planning activities. This list is based on the ART Readiness Workbook in the SAFe® PI Planning Toolkit and is available to RTE and SPCs in good standing.

You can’t underestimate the amount of planning that is necessary or the time and effort it takes to get organized. One thing to keep in mind is that the RTE shouldn’t try and do it all themselves. Leveraging support from the Scrum Masters/Team Coaches, Product Owners, Product Management, and System Architect will help make the event successful.

The RTE is like the ringmaster in a circus, coordinating all the parts and announcing the various activities, but ultimately relying on the other performers for their individual pieces.

Preparing Attendees

You will want to ensure that all PI Planning attendees understand the expectations prior to the PI Planning Event. Make sure that all members of the Agile Teams have completed SAFe® for Teams. Hold an overview of PI Planning for any Stakeholders that haven’t attended a SAFe® class or past PI Planning Events. Consider spending some additional time with the Business Owners discussing PI Objectives and how to assign Business Value. Lastly, make sure that Product Management and the System Architect have agreed on Capacity Allocations for Features compared to Enablers and technical debt.

Pro tip

Leverage the PI Planning Overview for Stakeholders slides from the SAFe® PI Planning toolkit.

The Day Before PI Planning

Depending on whether you are holding a virtual or in-person PI Planning Event, you will want to ensure your environment and space are prepared at least the day before. If it will be virtual, you can work on this during the weeks leading up to the event.

For in-person events, typically, the day before or right after the I&A workshop, the room needs to be set up and configured for the event. This includes building the ART Planning Board, Risk Board, and the team areas and boards. You want to ensure that when the teams arrive for the first day of PI Planning, they are able to jump directly into a successful event and not spend time creating their work environment.

With virtual events, you will need to ensure that your tools are configured with the appropriate boards. All ART members have links to the locations of the boards, virtual rooms, tools, and logins. Consider holding a session prior to the event to familiarize ART attendees with the tools and breakout spaces.

The preparation for PI Planning can’t be undervalued. Ensure you put in the time and effort to have a successful event. While each event is unique, you will quickly learn that you can leverage what’s learned from one event in the next one.

Executing PI Planning

The PI Planning Event is typically 2 days long. Depending on whether you are in person or remote or have distributed teams across multiple time zones, you may want to span the event across a greater number of days for shorter durations each day.

Figure 10.1 depicts the standard PI Planning Event schedule. We will walk through each activity in detail.

Figure 10.1 – PI Planning Schedule (© Scaled Agile, Inc.)

There are several PI Planning schedule variations in Appendix B.

When preparing for PI Planning, be sure to use the SAFe® PI Planning Toolkit. It is a rich resource that can help ensure a successful PI Planning Event. The SAFe® PI Planning Toolkit is only available to SPCs and RTEs in good standing.

Let’s take a deeper dive into the various parts of the event.

Day 1 Kick-Off

Day 1 starts out with breakfast! One of the most important items at a face-to-face PI Planning Event is food. If remote, consider putting together a box and sending it to each attendee with various goodies, including coffee, tea, snacks, and candy or sweets. Once the ART has gathered, the RTE will kick off the event with the Welcome segment of the presentations.

Presentations

We start with the Business Context, followed by the Product/Solution Vision, then the Architectural Vision and Development Practices, and lastly, the Planning Context. We have a 4-hour time slot for these presentations.

Pro tip

This part of the PI Planning Event can feel a lot like a bunch of talking heads. Toward the end of the 4 hours, everything may begin to sound like Charlie Brown’s teacher. Wah-wah, wah-wah-wah. To avoid this, make sure to plan short breaks (especially if remote) and work with the presenters to ensure that they avoid reading slides. Encourage and even push the ART to ask clarifying questions (even if you have to plant a few questions to get things going).

Welcome

When you look at the typical PI Planning Event schedule, the Welcome is often overlooked and combined with the Business Context. As the master of events, the RTE should open the event, spend a few minutes welcoming folks, talk through the high-level schedule to set expectations, and consider introducing key ART members.

The PI Planning Event Template from the PI Planning Execution Toolkit has a handful of slides to help set the context for the event, including why we are here, the agenda, working agreements, and some initial guidance.

If in person, consider identifying each table by its team so that the room is aware of where everyone is located.

The Welcome should last 15 minutes or less. At the end of the Welcome, the RTE can introduce (with excitement) the executive, who will present the Business Context.

The Business Context

The Business Context sets the tone of the PI Planning Event. We want executive leadership to share the state of the business and its upcoming objectives. There isn’t a prescribed format; it depends on the executive who is presenting and the needs of the ART.

When working with the executive on how to prepare, ensure that key portfolio priorities are communicated, as well as how the solution that the ART is developing fits into the portfolio and organizational strategy.

Sometimes, a SWOT analysis is used to help convey where the solution fits in the big picture. Ensure that the WHY is communicated, which is important for the ART to deliver.

You may need to Coach the executive on how to be personable and approachable in their presentation. An overall understanding of what the ART is delivering is key. An hour is allotted to the conversation that the executive holds with the ART, which should include a Q&A.

Identifying the Executive

Depending on your organization, it may not be clear which executive can effectively lead the Business Context conversation. It would be highly beneficial for the President or CEO to spend an hour with the ART and set the context; however, this may not be feasible. Identify an executive who is the most senior person available, has direct knowledge of the work the ART is executing, is powerful enough to make decisions, is respected within the organization, and can potentially spend additional time at the PI Planning Event and attend future System Demos (ideally the Iteration System Demos, but especially the PI System Demo).

Pro tip

Depending on your organization, you may have the opportunity to have several executives attend and set context and/or rotate executives depending on the solution being developed.

Story from the real world

I had an occasion where the night before PI Planning, the senior person delivering the Business Context phoned me to say that he couldn’t attend the PI Planning Event because of a major company merger. At that stage, my only option was to get one of the other Business Owners to present his slides on his behalf, which is never ideal. Because this wasn’t the only time this happened, going forward, I now always get the person delivering the Business Context to create a video recording. Not only does it give me a backup if the person can’t attend but it also means that I am never chasing the Business Context at the 11th hour!

By the end of the Business Context discussion, ART members should understand how their work directly impacts the business and why the work they are doing is important.

Product/Solution Vision

“If you don’t know where you are going, any road will get you there.”

– Lewis Carroll

The purpose of the Product Vision (and Solution if you are part of a Solution Train) is to lay out the plans for the ART’s PI. We dedicate 1.5 hours to this conversation, which can seem long and overwhelming if not well thought-out and prepared.

Product Management is responsible for this part of the PI Planning Event presentations. Product Management should be prepared to share the vision and the Features that the teams will work on during the PI.

The Vision

You should plan to work with Product Management to define or refine the vision prior to each PI Planning Event. Ensure that the vision communicates strategic intent, is inspiring, and is both aspirational and achievable. Consider leveraging a postcard from the future or a draft press release to help create the vision.

Figure 10.2 – Sample postcard from the future

Roadmap

Once we have articulated the vision, we recommend reviewing the Roadmap. We should be able to see a direct correlation between the vision and the Features on the Roadmap. The Roadmap is a useful tool showing not only where we are going but also where we have been. Since PI Planning occurs during an IP Iteration, we recommend showing what was completed in the last PI, as well as looking ahead at the current PI and the next few PIs.

Table 10.1 – Example PI Roadmap

Pro tip

Product Management may have several different Roadmaps that they use depending on context. I recommend at least three Roadmaps:

• A 3-5 year high-level portfolio Epic Roadmap
• A 1-2 year high-level ART Epic/Feature Roadmap
• A PI Feature Roadmap showing past, current, and next PI Features

Discussing Roadmaps is an opportunity for Product Management to congratulate the ART on its progress thus far and celebrate what the ART has delivered and accomplished. Also, as the ART matures, this can be a good opportunity to spend 10-15 minutes reflecting on the state of the ART one year prior.

Feature Review

After reviewing the Roadmaps, Product Management can delve into the Features that they would like the ART to deliver in the PI. Remind Product Management and the ART that this is a prioritized list and the teams may not be able to accomplish everything. The prioritized list of Features is the input for PI Planning, not the output.

Note

The teams should already be familiar with the Features being presented. PI Planning is not the time to introduce new Features to teams. Leverage the ART Kanban to mature the Features for consumption during PI Planning.

The Features presented should also include Enabler Features, and if there are milestones that certain Features need to achieve, that should be called out here too; make sure the milestones are captured on the ART Planning Board.

Product Management may want to involve the System Architect to present and answer questions about any Enablers. Product Owners can get involved in presenting and discussing some of the Features.

SAFe® materials typically refer to presenting the top 10 Features. This doesn’t mean that you must have exactly 10 Features for each PI. However, it is a good rough rule of thumb. If you find that your ART has significantly more or less than 10 Features in each PI, you likely need to spend some time maturing and sizing your Features.

Pro tip

There isn’t an exact science to the right number of Features for an ART, but the size of the ART can be a factor. If you have 5 teams, then maybe 10 Features might be okay (2 Features per team), but if you have 12 teams, then 10 Features don’t add up to one Feature per team.

Plus, a Feature (such as a story) needs to be small enough to fit inside a PI. So, I recommend that a Feature takes 1-2 iterations to deliver, with 3 iterations as the upper boundary. Lastly, we need to have enough Features not to starve the teams in the PI.

When creating slides for the Feature Review, consider creating a slide showing the prioritized Features and then a slide for each Feature with the following details:

• The Feature Title/Description
• The Feature ID (the unique identifier assigned by an Agile tool)
• The Benefit Hypothesis Statement
• Acceptance Criteria

ART members should ask questions for clarification as needed on the Features and vision. By the end of the Product Vision section of the PI Planning Event, ART members should be aligned with the vision and understand the Features that need to be developed and their levels of priority.

Architectural Vision and Development Practices

We often see this presentation as the most overlooked and the least prepared briefing. However, it is one of the most critical ones. You are likely familiar with the phrase “You can’t scale crappy code.” The same holds true with Architectural Vision and Development Practices. As a Coach, ensure you are working with the System Architect to help prepare.

The PI Planning schedule sets aside 1 hour for this conversation. From a logistics perspective, taking a short break before this section is recommended so that folks can return with better focus.

Depending on the solution your ART is building, this briefing will vary greatly depending on your context (e.g., hardware versus software). Consider the various roles that may need to share information in this section:

• The System Architect usually presents the architecture, the Enablers, and common frameworks and models
• UX leads will provide guidance on the UX
• Development management or members of the system team will provide updates on tooling, environments, the DevOps pipeline, or engineering practices

Enabler Features

This is an opportunity (if it has not already been taken during the Product Briefing) to discuss in further depth the Enabler Features for the ART for the PI. We recommend creating a slide for each Enabler Feature, including the information just referenced. Also, include links to where teams can learn more or find additional information, such as on models, NFRs, and so on.

Models

“A picture is worth a thousand words”

– Unknown

One often overlooked key component is architectural models and diagrams. While it isn’t always necessary to go through the models during the briefing, ensuring that teams know where the models are, how they can leverage them, who updates them, and the different models that exist will secure alignment.

When reviewing the architecture, a System Architect uses models like Product Management uses Roadmaps. Scenario models can help to show how information flows through various systems. Architectural models can show how all the systems interact with each other. Encourage the teams to reference and update the models throughout the PI.

Pro tip

Encourage Product Management and the System Architect to create scenario models for each Feature to show who and what systems interact with each other as work flows through the system.

Development Practices

The discussion around development practices will be drastically different if the ART is building hardware compared to an ART delivering software. Development practices for a hardware ART may include safety discussions, how to best leverage Model-Based System Engineering (MBSE), the use of 3D-printed doubles, and so on. For a software-centric ART, this might include updates to versions of various components, information about the build process and DevOps pipeline, discussions about the environments, or other various engineering practices.

Pro tip

MBSE is a systems engineering approach that focuses on developing and using models to support the system requirements, design, analysis, verification, and validation throughout the life cycle of a system. MBSE uses formal and graphical models to describe the system’s structure, behavior, functions, and requirements.

MBSE replaces traditional document-based systems engineering with a more modern approach that leverages computer-based modeling tools to create and manage system models. This allows for a more agile and iterative development process, which enables engineers to quickly analyze and validate system behavior, identify and resolve issues early in the development cycle, and make informed decisions based on system models.

MBSE is widely used in industries such as the aerospace, automotive, defense, and healthcare sectors, where complex systems require rigorous design and analysis processes. MBSE has been shown to improve system quality, reduce development time and cost, and improve communication and collaboration among team members.

This is a good time for the UX team to present information regarding the experience we expect of the users and to share wireframes or information from UX studies and updates to the existing systems. By the end of the Architectural Vision and Development Practices section, the ART members should understand any changes to their environments that may impact development. They should understand the priority of working on Enablers and ensure that UX guidance is incorporated into their stories.

Pro tip

One last area I like to include in the Architectural Briefing is testing. This conversation should include information about test data management, test doubles, testing infrastructure, automated test coverage, and so on.

Planning Context

Now that the teams understand the impact of their work on the business, what the vision and highest priority Features are, how the Features will be enabled, and the architectural and engineering concerns that need to be addressed, we finally get to talk to the teams about how to actually plan the work that has been articulated.

Pro tip

If you look at the standard SAFe® PI Planning schedule, it reads Planning Context and Lunch. I have found that having lunch first and then providing instructions and guidance allows teams to discuss and digest everything they have learned. The conversations focus on the work to be done, not how to do the work, and it helps to designate this lunch slot so that teams don’t start the team breakouts early. Remember, food and breaks are important.

The Planning Context discussion typically takes between 30 and 45 mins depending on the maturity of the ART and the consistency of location, tools, and practices from PI Planning Event to PI Planning Event. It is typically presented by the RTE; however, this is often an opportunity to provide growth opportunities to others on the ART.

The Process

When discussing the Planning Context, it’s important to share how the vision, Features, and Enablers are transformed into the outputs of PI plans, objectives, and the ART Board. The important takeaway is to draw a connection between what the teams learned this morning and what they will deliver at the end of the event. Reinforce why we are doing PI Planning.

PI Objectives

One of the biggest hurdles for many ARTs is PI Objectives. The RTE will want to spend some time discussing the PI Objectives and can use slides from the PI Planning Toolkit to help teams understand the expectations.

Remind teams that they should write Specific, Measurable, Achievable, Realistic, and Time-bound (SMART) Team PI Objectives.

Pro tip

Consider holding a PI Objective Writing workshop prior to the PI Planning Event to help the teams learn how to write effective PI Objectives.

Lastly, remind the teams that Uncommitted PI Objectives are not a stretch or extra work they will get done if they have time. Uncommitted PI Objectives are planned work for which the team sees risks, a significant amount of uncertainty, or significant dependencies and the team lacks confidence in their ability to deliver the objective.

Watch that teams don’t have too many Uncommitted PI Objectives and don’t be afraid to dig in and understand where and why the team feels they can’t commit; then, work to help the team make any adjustments to the plan to improve confidence.

As a note, we aren’t saying you shouldn’t have Uncommitted PI Objectives. We are saying to have Uncommitted PI Objectives within reason. We use PI Objectives to determine the ART’s predictability; a predictable ART meets between 80% and 100% of its PI Objectives. If your ART is consistently very near or above 100%, push the teams to determine the real reason for Uncommitted PI Objectives and challenge them to make them committed PI Objectives. You may also need to work with the Business Owners to help them understand their responsibilities in assigning Business Value.

PI Objectives are a measure of work completed. When Business Owners review the PI Objectives at the end of PI, they are asking whether you completed all the work, in the required timeframe, at the agreed level of quality.

However, when assigning Business Value at PI Planning, the Business Owner uses a scale of 1 (lowest) to 10 (highest) and will typically assign the highest values to the customer-facing objectives. However, they should also seek the advice of technical experts, including the System Architect, who know that architecture and other concerns will increase the team’s velocity in producing future Business Value.

Pro tip

Consider having the team define the risks around the Uncommitted PI Objectives. This can help identify whether the team has Uncommitted PI Objectives due to overplanning and creates an opportunity to ensure that the team receives the necessary assistance to eliminate risk and possibly commit.

PI Objective Tips and Tricks

Many teams and ARTs struggle with PI Objectives. Here are some tips and tricks to help your ART. You will have to continually work with the ART to improve PI Objectives; it doesn’t happen naturally.

To ease teams into PI Objectives, consider leveraging the concept of Iteration Headlines or Intentions and evolve from there. An Iteration Headline or Intention is a quick statement that articulates the key work the team is planning to deliver in the iteration; for example, “Extra, Extra, the Shark Team is building the shopping cart in Iteration 3,” or “the Pelicans intend to deliver credit card processing in Iteration 4.”

Story from the real world

I was working with an ART that had a number of interns working with the teams. We shared the example of headlines starting with the phrase “Extra, Extra, read all about it!” One of the interns asked me later what that meant. She had no context for newspaper extras. We subsequently changed the example and determined that we wanted the teams to create a “tweet” instead: “Sharks will reduce the wait time for the queries by 25% #WaitTime #Reduction.”

As a Coach, ensure the team doesn’t write too many PI Objectives. The general guidance for teams could be recommending the number of iterations plus one. So, if you have five iterations in your PI, then recommend between four and six PI Objectives for each team.

When we write PI Objectives, we often see them relate directly to the Features or Enablers in the ART Backlog. Other times, they are an aggregation of a set of Features, relating to milestones such as a trade show.

Pro tip

Make sure to avoid your teams writing PI Objectives that only correlate directly to the Features. Too often, I have seen team PI Objectives that look like this:

1. We will deliver Feature X in iteration 2.

2. We will deliver Feature Y in iteration 4.

Be sure to try and avoid this anti-pattern.

Consider leveraging one of the following formats:

• To improve end users’ efficiency in ________ (things they already do), we will ________
• To reduce or eliminate security risks, we will ________
• To improve ________, we will ________

Assigning Business Value

Assigning Business Value is very tricky for many Business Owners. There are some items that they should consider when assigning the value to avoid only associating it with the bottom-line return on investment:

• Regulatory value – Legal or infrastructural value that could result in fines, loss, or damage to the brand if not achieved
• Commercial value – A product or service that maintains or brings in new revenue
• Market value – Functionality that differentiates the solution to stay competitive
• Efficiency value – Functionality that improves the pipeline or reduces operating costs, including technical debt
• Future value – Functionality to support future needs including Enablers, proof of concepts, and spikes

As a Coach, you will want to work closely with the Business Owners prior to the PI Planning Event to help them understand how to assign Business Value and what they should be looking for.

Pro tip

PI Objectives help the team understand the priority of the work they are completing from the point of view of the Business.

Too frequently, I see teams that have 4 or 5 objectives with a Business Value of 10 and other teams with most of their objectives sitting at 6 or 7. This can largely demoralize the team whose work is viewed as less important.

One success pattern to leverage is to allow a single Business Value to be assigned to a PI Objective for each team. For example, each team would have one 10, one 7, one 3, and so on. This helps the team understand the priorities and Business Owners more evenly distribute value across teams.

Planning Context - Continued

We now want to make sure that the teams understand the layout of the room or virtual space and their work areas. Each team should have a board that is clearly labeled for each iteration, including dates, which includes spaces for capacity and load. Each team should have a board for PI Objectives and a board for Team Risks.

Figure 10.3 – Example Team Iteration Board

Explicitly call out and ensure there is a board for the IP Iteration and it is clearly marked to indicate work should not be planned in the Iteration.

Pro tip

Capture the Capacity and Load on sticky notes so they can be easily changed as plans change.

Pro tip

We have added at the bottom of the Iteration Board example in Figure 10.3 an area to record planned leave during the Iteration. Add the individuals’ names and the dates they will be absent. This provides clarity when we review the Capacity.

Pro tip

We have added an area called Iteration Headline to the bottom of the board. This helps other teams understand dependencies and what is planned to be delivered in each Iteration. Ideally, all teams will be able to review the stories and work on all the other teams’ boards; however, this is rarely the case. The headline/tweet is a quick way during the Plan Readouts to share what is happening each Iteration. It can subsequently be input for the Iteration Goals.

A legend in the team space is also helpful so that teams are consistently using the same color sticky notes for each type of work – for example, Stories are green, Enablers are yellow, Spikes are orange, Risks are red, Features are blue, and so on. This provides the ability to quickly look at the space and ensure that we have a good Capacity Allocation or that we don’t see all the Spike stories at the end of the PI.

Pro tip

You can change the sticky note colors from PI Planning Event to PI Planning Event if needed. When purchasing sticky notes, often, multiple colors are bundled together. Inevitably, you will use more Story sticky notes than Enabler or Spike sticky notes in a single PI Planning Event. You can rotate the colors at the next PI Planning Event so long as all the teams are consistent, and you explicitly clarify the colors.

Share and provide the Team Deliverables – Detail slide from the SAFe® PI Planning Toolkit to the teams. Ensure that teams know how to track dependencies, risks, and reserve capacity for unplanned activities such as maintenance and production support. Clearly set expectations for the IP Iteration. Remind teams that the PI Objectives should be drafted by the end of the first team breakout and will be assigned their Business Value during the second team breakout session. Lastly, ensure ART PI Risks are captured on the ROAM Board.

The ART Planning Board

Now that you have drawn attention to the location of the ROAM Board, you can naturally shift focus to the ART Planning Board. Ensure that Agile Teams and Scrum Masters/Team Coaches understand the information that should be captured on the ART Planning Board. Remind the teams that red string is a good thing. We want to make sure we capture the dependencies, which will highlight bottlenecks so that we can address or resolve them, thus enabling the ART to be able to meet its commitments.

The ART Planning Board is a large grid that is customized for each ART and each PI. The vertical columns identify the teams, each iteration, and a column for beyond the PI. The rows capture milestones and include a row for each team and a row for any additional teams/ARTs that this ART or its teams depend on.

Figure 10.4 – Example ART Planning Board

Ensure that you call out the various aspects of the ART Planning Board. You will want to call out any known milestones (again). Highlight the order of the team rows. Remind the teams to use blue (or another color you have determined) sticky notes to capture when the Feature will be completed. Use red string and sticky notes for the dependencies.

Pro tip

Strategically place the teams on the ART Planning Board to minimize the length of the red string between teams. For example, if you have two teams that typically have a lot of dependencies between them, you might consider placing them near each other.

If you have any specific formats for how teams should capture dependencies, now is a great time to address those practices. Some common items to consider are:

• What the dependency is
• Who needs what information, code, and so on
• Who is responsible for providing it
• When it is needed by

Remind the teams that they need to both agree to and accept the dependency when it is placed on the board. Team members should meet with each other to discuss and get agreement regarding the dependencies.

Take the opportunity to remind the Scrum Masters/Team Coaches that it is their responsibility to ensure the ART Planning Board is continually updated throughout the entire PI Planning Event, not just at the end of the second team breakout; however, they do not necessarily have to be the person to do so.

Pro tip

When identifying dependencies, I have found success in ensuring that the story numbers for both teams are captured on the sticky notes on the ART Planning Board for the work being completed by each team. I also have teams add dots to the sticky notes on their respective Team Boards with the story number from the other team – yellow dots for the teams that need information from another team and blue dots for the teams providing the information.

We are then able to cross-reference the Team Boards with the ART Planning Board. It also helps to ensure that the teams discuss the dependencies with each other and don’t overlook key dependencies in the frenzy of the PI Planning Event.

Before wrapping up the layout of the room and boards, consider calling out the following:

• Retrospective Boards
• Kudos Boards
• Team table locations
• Establishing a Parking Lot/Help Needed board
• Where to find Business Owners

Planning Procedures

We are now ready to move on to the steps we need the teams to complete for the planning itself. Consider leveraging the slides from the SAFe® PI Planning Toolkit and customize them to your environment and situation. We recommend including the Planning Procedures slide (or a variation of it) as a handout for the teams. This will help them stay on track. You will want to walk through the steps at a high level and make sure to not read the entire slide.

The key items the teams need to execute are as follows:

• Estimating Capacity for all Iterations: Leverage the planned leave area we recommended on the team boards when estimating the capacity. Use historical data whenever possible. The formula for calculating story points should only be used for teams that don’t have historical velocity.
• Make sure to capture any holidays that are occurring in each iteration: You may want to create a handout of observed holidays, especially if you have teams that aren’t geographically co-located. Don’t forget to include regional and religious holidays.
• Reviewing ART Backlog Items: The teams should already be familiar with the Features and Enablers by this point; however, it’s possible that additional questions have arisen that need clarification.
• Identifying Team Backlog Items: The team should identify the stories and estimate each. There are multiple schools of thought on whether teams should come to PI Planning with their stories created and estimated. Do what is best for your ART, its maturity, and its familiarity with the work.

Pro tip

For stories identified during PI Planning, break traditional planning poker guidance, and use majority wins, playing only one round. If someone is overly passionate about the estimate, they will typically speak up and the team can then decide whether they agree with that person’s perspective.

Remember that in PI Planning, we are looking to understand what we can and can’t deliver and then make a trade-off as needed. Don’t let teams go down a rabbit hole on every story or argue points indefinitely.

• Identify any hard delivery or commitment dates: Ensure that the team is aware of the milestones and any dates or lead times that may be needed to meet certain deliveries. Consider adding these to both the ART Planning Board and the Team Boards.
• Identify, discuss, and address interdependencies continuously: This is the most important aspect of PI Planning. Ensure you remind the teams again about your practices for capturing dependencies.
• Load stories into the iterations: Teams will add sticky notes to each Iteration Board, completing the highest priority Feature first and then the next until capacity is reached. Consider guiding teams to split any story that is eight or more points.
• State, negotiate, and gain agreement on PI Objectives: The PI Objectives should be captured on each team’s board. You may want to consider having the teams write the first draft on large sticky notes to allow them to be refined before finalizing them on Day 2.
• Identify impediments and risks: The team should capture both Team and ART PI Risks. You may want to consider providing guidance on how the risks should be written.
• Prepare to present the plan: The team should identify who will be responsible for presenting the plan readouts. Often, this is the Product Owner or Scrum Master/Team Coach; however, any team member can present it.
• (Bonus) Iteration Headlines: If you decide to leverage the Iteration Headlines, make sure those are also created to be shared during the Plan Readouts.

Story from the real world

I have coached numerous ARTs and have yet to see an ART that could take a Feature and completely decompose, estimate, and plan it during the PI Planning Event. I strongly encourage communicating the Features to the teams and breaking them down prior to PI Planning.

This does not mean that all the stories are fully refined with full Acceptance Criteria and would meet the Definition of Ready, just that there is enough information that the team understands what the story is and can give it a quick estimate.

I would expect that the stories in the first two iterations would be more refined than those in iterations 3 and 4.

You will want to watch that the teams aren’t coming into PI Planning with everything planned and spend their time just putting the stories on sticky notes and attaching them to the wall. If this is occurring, teams are overplanning and subsequently losing the value of PI Planning, so conversations will need to occur about the work being done.

The challenge is to find the right balance between not identifying any of the stories and having all the stories ready.

Planning Acceptance Criteria

As we near the end of the Planning Context section, we want to ensure that everyone understands the Acceptance Criteria for completing PI Planning. There are three key criteria:

• All iterations are planned and plans are accepted
• PI Objectives have been created and Business Value assigned
• ART PI Risks have been captured

You may want to consider some additional Acceptance Criteria to provide additional clarity to the teams, including the following:

• The Load should be less than the Capacity for each Iteration
• Dependencies have been captured and agreed to
• The ART Planning Board reflects team plans

Before dismissing the teams to their breakout rooms, take the opportunity to answer any final questions from the participants. Then, with excitement and enthusiasm, send the teams to the breakout rooms.

This concludes the Planning Context and the Day 1 Presentation part of PI Planning.

Team Breakouts

There are two different team breakout sessions that occur during PI Planning, one occurring each day. The Day 1 breakout is 3 hours long. During this time, the teams develop their plans, resolve dependencies, identify risks, write PI Objectives, and prepare their draft plans.

There is a lot of discussion and decision-making that happens during those 3 hours. The teams should be fully engaged.

During the breakouts, the RTE, Product Management, the System Architect, and Business Owners should circulate among the teams, answering questions and providing clarification as needed. You will want to watch that someone doesn’t get “stuck” with a team and inadvertently de-rail the planning process for the team.

Coach Sync Checkpoints

Every hour or so, the RTE will hold a Coach Sync checkpoint. During the Sync, the RTE will review a list of activities and the progress the teams are making toward their goals. The SAFe® PI Planning Toolkit includes a template for the Coach Sync checklist. Feel free to tailor it to your ART and the timeboxes when adjusting for distributed PI Planning.

Pro tip

Give your Scrum Masters/Team Coaches the Coach Sync checklist before PI Planning so they know where they need to be in the process hour by hour.

The Coach Sync creates several opportunities. First, it gives the Scrum Masters/Team Coaches a chance to break away from teams for a few moments to catch their breath. Second, it provides an opportunity in the meet-after to discuss any dependencies. Third, it’s a good time to spend a few minutes updating the ART Planning Board. Fourth, it creates a natural break in the timebox for folks to get coffee, use the facilities, and so on.

At the end of the Team Breakout session, consider taking a short break and then bring the groups back together for the Draft Plan Reviews.

Draft Plan Reviews

The Draft Plan Reviews follow a structured format for each team. It is helpful if the teams know what order they will be presenting in, but not absolutely necessary. Anyone from the team can present the draft plans.

We are looking for the teams to present the following information:

• The Capacity and Load for each Iteration
• The Draft PI Objectives
• The ART PI Risks and Impediments
• Q&A

We advise you not to dive into the stories, as this can quickly cause the review to become extremely lengthy. Additionally, your PI Objectives should be clear enough that there isn’t a need for additional clarification. ART members should take the opportunity to ask questions about the work and the plans the teams are planning to deliver.

Pro tip

I have rarely found that teams are able to write clear SMART PI Objectives, even with extra work and training, but I have found that teams are easily able to summarize the work they are planning to complete in an iteration with a single sentence, which is why I promote the use of Iteration Headlines/tweets.

I typically give the team a script pattern to follow. Here is an example:

“In Iteration 1, Team Lizard has a capacity of 26 and a load of 25. Our headline is: Building the initial UI and data structure for the shopping cart.

In Iteration 2, we have a capacity of 28 and a load of 28. Our headline is: We will finish the shopping cart Feature.”

Note the call-out here of when the Feature will be completed. I even encourage the teams to capture the Features as sticky notes on their boards, not just on the ART Planning Board.

After going through each iteration, the presenter then shares their PI Objectives and any risks and impediments. I have encouraged Business Owners to take some notes and they can help the teams improve their PI Objectives during the Team Breakout on Day 2.

At the end of the Draft Plan Reviews, make sure to thank all the ART members for their hard work and celebrate with cheers and applause. Some ARTs even have optional dinners or happy-hour options arranged. If yours does, share the details and then dismiss the ART, except for those needed for the Management Review and Problem-Solving.

Management Review and Problem-Solving

The Management Review and Problem-Solving part of PI Planning can be the hardest. The RTE or Coach facilitates it. It should be allotted one hour; however, depending on the challenges faced by the ART, some discussions and work may continue beyond the timebox. The facilitator will need to pay attention to the timebox and keep discussions moving.

One technique is to have the participants move around the room, leveraging the ART Board and each of the Team Boards.

Some key questions to address during this session are as follows:

• What did we just learn?
• Where do we need to adjust the vision? Scope? Resources?
• Where are the bottlenecks?
• What Features must be de-scoped?
• What decisions must we make between now and tomorrow to address these issues?

You will want to capture notes and action items and decisions that are made during this time, as they will be presented to the teams to make the necessary adjustments in their Day 2 breakouts.

Pro tip

Do not bring in dinner (coffee could be helpful) for the participants in the Management Review and Problem-Solving session. It prolongs the day and hunger is a good deterrent to lengthy conversations.

Encourage participants to make decisions quickly and then join their colleagues at dinner/happy hour.

Management Review and Problem-Solving Participants

Identifying the participants for the Management Review and Problem-Solving session can be difficult. You will find that a lot of people want to be involved or believe they should be involved. Setting expectations prior to the PI Planning Event helps to smooth the process.

Depending on your organization, the participants will vary. Keep the group as small as possible. If you find that there are more than your typical Agile team size of 7+/-2 participants, you will want to work to minimize that number. Here is a general success pattern for participants:

• The RTE
• Product Management
• System Architect
• Business Owners
• Executive leadership (Epic Owners)

Pro tip

I often see Product Owners and Scrum Masters/Team Coaches included. If you do choose to include the Product Owners and Scrum Masters/Team Coaches, ensure they understand the expectations and that they should be observers, not active participants. It’s my experience that they often cause delays in decision-making and lengthen the session.

Instead, encourage them to retire and get a good night’s sleep and then update them in the morning, prior to the start, with anything they specifically need to be aware of.

By the end of this session, participants should agree regarding the decisions that have been made. Identify who will present the changes and decisions to the teams and who will create a slide with these decisions.

If following the traditional schedule, this formally concludes Day 1 of Planning.

Day 2

In the same spirit as Day 1, kick off and welcome the participants back to PI Planning.

Planning Adjustments

A 30-minute timebox is allocated to review the decisions made during the Management Review and Problem-Solving session. Typically, the person that owns the actions and adjustments will present the adjustment and answer any questions. For example, if it is a scoping issue, then Product Management will discuss it while if it is related to Architecture, then the System Architect would clarify the changes. Ensure that the teams have an opportunity to ask questions about the changes. You may want to consider planting a question or two to break the ice.

Day 2 Team Breakouts

Teams use the breakout on Day 2 to refine and adjust their plans based on feedback from the Management Review and Problem-Solving session. Teams may need to replan based on Features that have been de-scoped or risks that have been resolved.

The teams have 2 hours for this session. Encourage the Business Owners to circulate to each team early and provide feedback and guidance on the PI Objectives, allowing the team to refine them before the Business Owner assigns Business Value near the end of the time box.

As on Day 1, the RTE, the System Architect, and Product Management should also circulate, and the RTE will continue to hold Coach Syncs.

Here are some key reminders before sending the teams into the second breakout session:

• Teams have 2 hours or until the end of the timebox to complete their plans
• Business Owners will circulate to provide guidance and Business Value to the PI Objectives
• Coach Syncs will occur at the specified time(s)
• Continue to identify dependencies, ensuring the ART Planning Board is updated
• Make sure to capture any Risks and Impediments
• Lastly, remind the teams to have fun

These are critical for the teams to stay on track and complete their plans. If teams find they have some extra time, you can encourage them to review the other teams’ boards prior to lunch and the Final Plan Review.

Final Plan Review and Commitment

Per the standard schedule, this section is titled Final Plan Review and Lunch. We encourage you to consider holding lunch first and then starting the Final Plan Review. This gives the teams a bit of a buffer to wrap up planning if needed.

The Final Plan Reviews occur in the same fashion as the Draft Plan Reviews. SAFe® guidance is to share any changes made to the draft plan; however, consider restating the entire plan, as some ART members may have a different perspective by this point, which may lead to additional questions.

Once the team has shared the Capacity and Load, PI Objectives, Risks and Q&A is completed, there is one step that is often overlooked that needs to be completed for each team; the Business Owners are asked whether they accept the team’s plan.

Ensure that this step is not skipped. Ideally, any worries or concerns from the Business Owners will already have been addressed; however, questions asked by other ART members may shed new information that may cause the need to replan.

If the team’s plan is not accepted, the PI Planning schedule has time built in for additional rework. Whatever has caused the plan to not be accepted may determine the remaining schedule for the day. You may need to decide to replan for a certain amount of time and then restart the review, or you may want to continue the reviews and Risks and then replan and finish the event activities.

Pro tip

You may find that after lunch, PI Planning participants are in a bit of a food coma. If you find this to be the case, you could have everyone stand up for 15 seconds between presentations to help keep participants actively engaged.

Once we have completed the Final Plan Reviews, it’s best to take a short break and then begin addressing ART PI risks.

ART PI Risks

During the course of the PI Planning Event, teams have added items to the ROAM Board. ROAM is the methodology we follow to address risks. A common format to capture risks is “if X, then Y.” Consider leveraging this format and capture the team or individual that identified the risk for additional follow-up.

Each risk will need to be ROAMed and placed in the appropriate quadrant:

• Resolved: The risk has been addressed and is no longer a concern
• Owned: Someone has taken responsibility for the risk
• Accepted: Nothing more can be done and if the risk occurs, the release may be compromised
• Mitigated: There is a plan to adjust as necessary

Figure 10.5 – Example ROAM Board

As you go through the Risks, you will want to capture additional notes about the Risk, including who owns the Owned Risks or notes on the mitigation strategy.

Once all the ART PI risks have been ROAMed, we can move on to the Confidence Vote.

The Confidence Vote

The Confidence Vote is held once the ART PI Risks have been addressed. There are technically two votes that occur. The first vote is the teams voting on their own confidence in meeting their PI Objectives as a team. The second vote is held to express confidence in the collective plan of the ART and all the teams.

The Confidence Vote is usually conducted as a Fist-of-Five vote, where members hold up the number of fingers corresponding to their level of confidence, with 1 being the lowest and 5 the highest.

Figure 10.6 – Fist-of-five Confidence Vote (© Scaled Agile, Inc.)

The confidence vote comes with a level of commitment to the following:

• The teams agree to do everything in their power to meet the agreed-to objectives
• If the teams identify that they will be unable to meet the agreed-to objectives, they will escalate immediately so that corrective action can be taken

For each vote, if the average is 3 or above, we should accept the commitment; if less, then we need to understand why and rework the plan. Any person voting 2 or below should be given an opportunity to voice their concerns. Based on the concerns, you may need to consider re-voting and subsequently replanning if confidence drops.

Pro tip

As the Confidence Vote occurs toward the end of the day, often, attendees are tired and ready to go home. If this isn’t their first PI, they are more aware that low confidence means staying later and will sometimes vote 3 to avoid having to stay longer or being called out.

You may want to consider an approach where you hear from everyone with a level of confidence of 1 or 2, and then get a couple of volunteers from the 3s, 4s, and 5s to share why they voted as they did.

Once you have agreement on the Confidence Vote and no replanning is necessary, or replanning is completed, it’s time for the PI Planning Retrospective.

Pro tip

One of my colleagues uses the Palm-of-Four instead of the Fist-of-Five. This prevents people from sitting on the fence with a 3. You are either a 1 or a 2 with relatively low confidence or a 3 or a 4 with relatively high confidence.

The Retrospective

The PI Planning Retrospective is a key part of the Planning Event, as this provides insight into how we can continuously improve. One of the challenges of the retrospective is leveraging the feedback constructively.

You won’t be able to please everyone and will regularly get feedback about common items. The food was good or bad, the room was hot or cold, there weren’t enough power cords, the technology sucks, and there was too much time or not enough time for breakouts. When reviewing the retrospective results, look for improvement areas beyond these types of items.

Pro tip

Consider adding and subsequently reviewing a Kudos board before dismissing the ART and closing out PI Planning.

You may also want to capture the retrospective items as folks exit the PI Planning Event. Usually, folks are pretty tired by the end of the event, and asking folks to add a sticky note to each board before leaving is the exit criteria for the event.

There are plenty of options for Retrospectives you can execute at the end of the PI Planning Event; ensure you keep it simple to ensure that participants are able to easily provide valuable feedback.

Close Out

Depending on how you execute the retrospective, you may want to combine or provide close out guidance prior to the retrospective.

In the Close Out, you will want to provide instructions to the team on how they should leverage the plans into their Agile Tools. Remind them of key dates and events. Ask for any necessary help cleaning up the rooms/spaces if necessary.

Be sure to celebrate the hard work that all the teams have completed. Also, don’t forget to take some pictures. Get photos/screen captures of the teams and the ART. You can leverage these photos at future PI Planning Events and in I&A.

Lastly, be sure to grab photos or screen captures of each of the team boards, the ART Planning Board, and ROAM board. You may need these for reference in the future and to facilitate transcription into an Agile Tool.

Congratulations on a successful PI Planning Event. It’s a long event with lots of details, coordination, and decision-making. In this section, we reviewed all of the key parts and understood the various aspects of the event. Let’s now take a look at some of the challenges you may encounter with remote or distributed PI Planning.

Remote/Distributed PI Planning

Let’s begin by clarifying the differences between remote and distributed PI Planning. Remote PI Planning is PI Planning where all participants are not located together. Distributed PI Planning is when we have participants executing PI Planning from multiple locations, where they are face-to-face in those locations.

We do not recommend having combined Remote and Distributed PI Planning if you can avoid it, although it is much easier post-Covid-19 than it was before due to the technological improvements made by most organizations.

When executing either type of planning, you will want to pay particular attention to several items. You will want to ensure that you have the best possible technology and tools you can get and that the participants know how to use and leverage them. This includes the breakout rooms, chat functionality, whiteboard functionality, and multiple concurrent users in the same workspace.

Particularly at a Remote PI Planning Event, you may want to consider spreading the event over a greater number of days for shorter durations. For example, consider four 4-hour days rather than two 8-hour days. Zoom fatigue is a real thing, and by shortening the days, you will likely get better engagement. Be sure to check out Appendix B for some example schedules.

For both Remote and Distributed Events, you will likely need to consider the time zones that individuals and teams live in. Leveraging multiple shorter days is one option; another consideration is to alternate staying up late or getting up early from PI Planning Event to PI Planning Event.

Story from the real world

An ART had team members from the US and India. The US participants were located primarily in Phoenix, Chicago, and Baltimore, spanning 3 or 4 time zones depending on the time of year. The teams in India were primarily located in Chennai.

To minimize the number of locations, the team members from the US would fly into Baltimore, and PI Planning was held at two distributed sites. At each site, we had one large room and five breakout rooms, one for each team, with conferencing technology so that the teams could hear and see each other between the sites. (Holding distributed PI Planning in a single room is too noisy for teams to effectively communicate with each other.)

For the first few PI Planning Events, we held them from 8AM EST to 4PM EST and colleagues from India would end up working late into the night. Based on feedback from the teams, we began experimenting with alternating schedules and changed locations. The teams decided it wasn’t fair for the teams in India to always work late.

We first tried starting at 3:00 AM Eastern Time/1:30 PM in Chennai to have more overlap. The teams decided that staying up late was easier than getting up that early.

For the second experiment, we held PI Planning in Phoenix and started at 6:00 PM Pacific Time/7:30 AM in Chennai and planned until 2:00 AM Pacific Time/3:30 PM in Chennai. The teams preferred this experiment to the first.

The teams continued various experiments and ultimately settled on spreading PI Planning over 3 shorter days and alternated between locations and start times. Sometimes, they would start at US 5:00 AM Eastern Time, and the next time, they would start at 5:00 PM Pacific Time.

The key here is that the teams worked to identify a plan where the burden wasn’t always on one group to stay late or get up early. The executives appreciated that the teams were working together and accommodated their schedules to participate.

Remote and Distributed PI Planning are challenging, so be creative in finding solutions to make them easier. Consider sending PI Planning packages to participants; these could contain food, funny hats, and so on. Make it fun and have a good time, even if everyone can’t be together.

PI Planning is a key event for the ART. A successful PI Planning Event sets the ART up for future success and the ability to deliver on their commitments. PI Planning is fairly rigid and prescriptive in its schedule and outcomes. When first starting, we recommend staying as close to the actual timeboxes and schedule as possible. Ensure that teams are coming in prepared but not planned, and most of all, have fun.

The I&A Event

The last formal event of the PI is the I&A event. This is a three-part event that occurs during the IP Iteration before PI Planning. The three parts are the PI System Demo, Quantitative and Qualitative Measurement, and the Retrospective and Problem-Solving Workshop. All ART members and Stakeholders participate. The intent of the event is to foster relentless improvement and drive a Continuous Learning Culture.

The PI System Demo

The PI System Demo is the first part of I&A. This demo shows all the Features that the ART developed during the PI. It is different from the Iteration System Demos in that the audience is broader and the demo tends to be more customer-focused and polished.

This demo should tell a story. Explain and show the customers’ journey to using the Features that were developed. We expect this demo to take about 1 hour. There is no requirement that every team presents individually.

Product Management typically leads this demo and works with the teams ahead of time to plan the demo, stage data, and execute a dry run.

Pro tip

The PI System Demo requires preparation. The RTE should consider scheduling several meetings leading up to the demo to ensure adequate preparation. You may want to consider having the Business Owner be the practice audience so they can already begin thinking about the Actual Business Value (ABV) for the PI Objectives.

Product Management should show the Features that have been completed and want to show and tell the story from the user’s perspective. Be sure to highlight and call out the benefits that the Features deliver provide, as defined in the Benefit Hypothesis for each Feature.

Story from the real world

One of the worst PI System Demos I ever attended was over 4 hours long and each team showed almost every story they had worked on during the PI. There was no continuity between the teams, no alignment with the Features they had completed, and it felt like a big, long iteration demo.

There was a misunderstanding of the intent of the PI System Demo and the belief was that the teams should show all of their work so that the Business Owners could see what they had accomplished so they could get the maximum Business Value.

Quantitative and Qualitative Measurement

The Quantitative and Qualitative Measurement section of I&A is an opportunity to review and reflect on what has been delivered. We use this opportunity to review any quantitative and qualitative metrics that are being collected and understand their data and trends.

A key metric we look at is the Predictability Measure. The Predictability Measure is derived from the Planned and Actual Business Value (ABV) from the PI Objectives.

Pro tip

Work with the Business Owners in advance to determine the Business Value. The dry runs of the PI System Demo are a great time to start socializing this. Also, consider setting up a meeting with each team and the Business Owners to review the PI Objectives and to have a conversation about each. This serves two purposes. First, it helps the teams and the Business Owners understand each other’s perspective, and, second, it often helps drive improvements in writing better PI Objectives in the future.

The Predictability Measure is a calculation that uses the planned versus the Actual Business Value of all the teams collectively.

Remember, when assigning Business Value at PI Planning, the Business Owner uses a scale of one (lowest) to ten (highest) and will typically assign the highest values to the customer-facing objectives. However, they should also seek the advice of technical experts, including the System Architect, who know that architecture and other concerns will increase the team’s velocity in producing future Business Value.

Then, when Business Owners review the PI Objectives at the end of PI and assign ABV, they ask whether you completed all the work, in the required time frame, at the agreed level of quality. The PI Predictability Measure is a measure of work completed, not the “actual value” received, which is why many find the term “actual value” misleading and often misunderstand it.

This metric is a trend metric that needs at least three PIs worth of data to really begin to be of value to the ART’s ability to predictably deliver work.

Figure 10.7 – ART Predictability Measure example (© Scaled Agile, Inc.)

Pro tip

Don’t let the teams game the Predictability Measure by having too many Uncommitted PI Objectives during PI Planning.

Also, ensure that teams don’t become demoralized if they don’t receive all the Planned Business Value. This is why the conversation between the Business Owner and teams is important. It’s possible that the landscape has changed and what was initially very important no longer is, or that the expected benefits weren’t realized.

While the key focus is on predictability, many factors feed into an ART’s ability to deliver predictably. Consider leveraging other metrics during this conversation as well, including the following:

• The number of deployments and releases
• The ART Cumulative Flow Diagram
• The Average Cycle Time for Features and Stories
• PI Feature Throughput
• Defect counts and ratios
• DevOps pipeline metrics

Ensure that whatever metrics you present have context and aren’t being used in a way that will “punish” teams. Use the metrics to highlight areas that teams may want to consider as opportunities to look at during the Problem-Solving Workshop, or celebrate where the teams are doing a great job.

The Retrospective and Problem-Solving Workshop

The Retrospective and Problem-Solving Workshop is the last part of I&A. Attendees include all ART members, key Stakeholders, Business Owners, and management. The timebox for this is typically 2 to 2.5 hours.

The Retrospective

The retrospective typically takes 30 minutes or less to identify a few issues that need to be addressed during the Problem-Solving Workshop. Once the issues have been identified and agreed to, they become the input for the Problem-Solving Workshop.

You can use any format you want for the retrospective; however, we recommend keeping it simple, as the intent is to identify challenges. Most of the time, the facilitator (typically, the RTE) will use a “what went well, what didn’t go well” format. Celebrate what went well and then leverage a quick dot vote on what didn’t go well to identify the key problems to solve.

Pro tip

The size of your ART can inform the number of problems you may want to take on during the workshop. I typically use the number of teams as a guide for the number of problems to be solved. Due to additional Stakeholders, Business Owners, and so on, the teams solving each problem will be slightly larger than a typical Agile team.

Once you have identified your problems, let folks vote with their feet and go work on the problem that resonates the most with them. Encourage teams to split up. If you notice one problem has a lot of people and another has only one or two people, consider splitting the large group into two and asking the small group to join another.

If this isn’t your first I&A, make sure during the retrospective (or potentially as part of the PI System Demo if applicable) to recognize the progress made toward delivering the identified improvement items from the last I&A Problem-Solving Workshop.

The Problem-Solving Workshop

The Problem-Solving Workshop is designed to identify the root cause of problems or issues that the ART is experiencing and identify solutions to improve them. The Problem-Solving Workshop is typically allotted 2 hours and has six key steps, concluding with a readout and adding the improvement items to the Backlog and PI Plan.

Each group will need a Problem-Solving Board to capture their work. The board has an area for each step in the process and a fishbone diagram.

Figure 10.8 – Problem-Solving Board (© Scaled Agile, Inc.)

Pro tip

Ensure that you have identified the number of problems you will solve during the event and have facilitators lined up to support each group. Spend time with the facilitators prior to the event to ensure they know how to facilitate each of the steps in the workshop and what to do or who to go to if they get stuck.

Step 1 – Agreeing on the Problems to Solve

This step will set the context for the remaining five steps. You will want to ensure that the teams are clear on the problem. They will want to state what the problem is, when it occurred, where it is happening, and, most importantly, the impact the problem is causing.

As we previously mentioned, the retrospective is a great place to identify problems. You might also consider leveraging Team and Technical Agility Assessment results. Don’t be afraid to use a pre-identified issue as one of the problems.

Step 1 is typically allotted 15 minutes.

Step 2 – Performing a Root-Cause Analysis

Once you understand a problem, your groups will want to really understand the root cause of this issue. SAFe® leverages a fishbone diagram, also known as an Ishikawa Diagram, and the 5 Why’s.

One common mistake folks make is misunderstanding that the bones on the fish are not static. Teams can leverage those as a starting point and add or change the bones as needed.

Step 2 is typically allotted 25 minutes.

Step 3 – Identifying the Biggest Root Cause

When teams get to this step in the process, they often get stuck realizing that they are just looking for the team to generally agree on what they believe ultimately was the root cause of the problem. We recognize we won’t get 100% agreement, and we are looking to identify 20% of the causes that are responsible for 80% of the problem. This is known as a Pareto Analysis.

Pro tip

Make sure that the facilitators don’t let teams go down a rabbit hole of solutions during this step. Remind them they will get the chance to brainstorm solutions in Step 5.

The simplest way to identify biggest root cause is by letting the team dot-vote on what they believe the biggest root cause is and then counting the votes. Now that the team has “agreed” on the root cause, we can restate the problem.

Pro tip

The 5 Why’s are often overlooked or shortened by teams. It seems redundant to ask the same question over and over and over and over and over again. However, teams that are diligent in this process and continually work to answer the question will often discover that what they thought was the real reason isn’t. Asking five times helps ensure that teams are putting in the work and effort to really understand the issue at hand.

Here’s a great video to check out about the 5 Whys: https://www.youtube.com/watch?v=BEQvq99PZwo

Note: sometimes, four whys are sufficient and sometimes it takes six. As a facilitator and Coach, the key is to not let the teams stop asking why too early.

Step 3 should only take a few minutes to complete.

Step 4 – Restating the Problem

Now that the team understands the challenges around the problem and has agreed on the root cause, we want the team to take a few minutes and restate the problem with their new understanding. The teams should ensure they include the What, When, Where, and Impact in a problem statement, similar to Step 1.

Step 4 typically takes about 10 minutes to complete.

Step 5 – Brainstorming Solutions

The brainstorming session tends to be the most fun and easiest for the teams. Encourage the team to come up with as many ideas as possible. Consider timeboxing this so that the ideas can be reviewed, aligned, and combined, and then dot-vote to identify the three solutions the team believes will solve the problem.

Step 6 – Creating Improvement Backlog Items

From the brainstormed solutions, create stories and Features that can be consumed in the following PI Planning. Depending on the number and type of solutions identified, the RTE will work with those necessary to ensure the identified improvements are planned.

Pro tip

Sometimes, the challenges that the ART identifies and provides solutions for aren’t within the scope of the ART to resolve. The RTE may need to leverage the Business Owners and management to address the problems and the backlogged solutions that the teams have created.

Closing Out

Give each team the opportunity to share their results and recommendations. Timebox this activity to 10 to 15 minutes if possible.

As the Coach or RTE, we encourage you to review all of the causes the teams identified, as well as the brainstormed solutions. You may identify some additional quick-win items that can be incorporated that didn’t potentially meet the 80/20 rule or receive the most votes but would still improve and help the ART.

Pro tip

Discuss the improvement item progress at various ART Events, such as the ART Sync, Coach Sync, and/or the Iteration System Demos.

Logistic Considerations

When holding the Problem-Solving Workshop, you will need to work through some logistics, both face-to-face and remotely:

• Ensure you have a space for each group to work in. If face-to-face, you can send teams to different areas around the room. If virtual, you will want to have breakout rooms set up for each problem.
• Make sure you have the instructions for the steps with examples available for reference during the event. Consider paper handouts if face-to-face.
• Pre-draw or pre-print the fishbone templates. If virtual, make sure that the workspaces can have multiple contributors and that the template is available online.
• Keep timers for each step and make timebox announcements to help keep the teams on track. Virtual groups may need to consider a way to message multiple teams at once.

There are a few key takeaways from I&A. First, we see how we are doing by demonstrating the actual system. Second, we leverage hard data to verify and validate our progress. Third, we take the opportunity to reflect and then determine how we can improve in the future. Too often, many folks gloss over the importance of I&A. Make sure you work with your teams to get the most value possible.

Summary

The PI Events are key events and define the success of the ART. PI Planning kicks off the ART and ensures alignment between the teams in order to deliver a quality solution. I&A at the end of the PI highlights the work that was delivered and creates an opportunity for improvement, enabling the ART to deliver even higher-quality results faster and with greater predictability.

Further reading

1. PI Planning: https://www.scaledagileframework.com/pi-planning/
2. Vision: https://www.scaledagileframework.com/vision/
3. SAFe® PI Planning Toolkit: Available from SAFe® Studio for RTEs and SPCs in good standing
4. ART Kanban: https://www.scaledagileframework.com/art-and-solution-train-backlogs/
5. Features: https://www.scaledagileframework.com/Features-and-capabilities/
6. Inspect and Adapt: https://www.scaledagileframework.com/inspect-and-adapt/
7. Alex Yakima (2016). The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®. Alex Yakima.