SAFe in a Nutshell – Preparing for PI Planning

In Part 1 of this series, we used the concept of scaling Scrum to present a simple way to understand how SAFe works at its core.

 

In this next blog, we’ll focus on how to get features ready for the next Program Increment (PI) and expand on the roles of technical authority, content authority, and execution authority in this process.

 

Prepping for PI Planning

In terms of the SAFe continuous delivery pipeline, prepping for PI planning falls into the continuous exploration phase. This is where organizations will identify features and get them to a ready state to move into PI planning.

 

One recommended practice in the continuous delivery pipeline is visualizing where features are in that pipeline, moving through the funnel where they start off as ideas all the way through to being done – they’re out in production and you’ve realized the value.

 

Learn more about our Five Lessons Learned to Prepare for Virtual PI Planning. 

Where do Features Come From?

There is a common misconception that features must come only from a portfolio epic. Portfolio epics can be broken down into features after the epics have been approved through the Portfolio Kanban. Those features would then start to feed the program backlog for the release train.

 

However, features can come from other sources such as from the product management team or members of the release train who propose the features themselves and may not necessarily be tied to a portfolio epic.

 

Roles

As you move through continuous exploration, a variety of activities occur in order to get features refined and moved to an approved state. One of the challenges of getting features ready for a PI Planning session is: how do you make sure you are effectively driving all the activities that have to happen in order to get that feature refined and in the ready state?

Let’s take a look at the roles below in addressing this challenge.

 

Content authority

As a refresher, the Content Authority is the scaled up Product Manager. Let’s deep dive into their role:

• • Customer centricity and design thinking

This is one of the key aspects of SAFe 5.0, which brings in concepts of personas and customer journeys. During PI Planning preparation, one critical activity that the Content Authority will focus on are techniques that truly help to understand the customer better and what their journey should be. A product centric view and a customer centric view of the backlog and value streams are important in defining features, as those features represent portions of those customer journeys that you’re trying to improve or capture in your product.

 

So, during this continuous exploration phase, the product management team and supporting members can use customer centricity techniques to help inform whether features are valuable and can therefore be included in the PI.

• • Setting goals

The goal is certainly not to have fully refined and sprint ready stories for the entire PI, walking into PI Planning. While it is often best to avoid excessive upfront planning, planning should be at a sufficient level of detail – enough that you would be highly confident in actually executing the plan during the PI.

 

Setting targets is key. For example, if you’re doing a 10 week PI for the current PI, by week five, the goal would be to have draft features for the next PI, so that you’re at least discussing them in the PO sync, getting feedback, and refining them. Your team could then set a goal that by no later than the end of the final development sprint, the ideal scenario is to have final features that are in the ready state. That would allow your teams to have the last sprint in the PI to understand those features, to start to author the stories associated with those features, and really get ready to walk into PI Planning with an understanding of that backlog while having some level of detail for the stories.

• • Preparing briefings

The first agenda item in the PI Planning session is the business context briefing that is generally delivered by the business owner. Generally, the product management team will work with the business owner to help craft the message of the business context briefing so that it aligns with the briefing the product management team is putting together surrounding vision and goals in the next PI.

 

From a big picture perspective, the business owner would prepare to set the business environment and the business context of the company and where it stands in the market, along with key challenges. This would then lead to a product management discussion on the vision of the product and what part of that vision should be implemented during this PI.

 

Technical authority

As a refresher, the Technical Authority is the scaled up System Architect. Let’s take a look at their role in preparing for PI Planning:

 

• • Architectural runway

The content authority will focus on the question: What kind of architecture runway or enablers do we have to do upfront to really enable ourselves to deliver those features that the product management team is asking for?

 

Throughout the PI, you will work with technical SMEs to understand the business features enough to know what architectural or exploration type enablers need to be defined ahead of time, then make sure those get to a ready state by the time you get to the end of the last sprint.

• • Technical sync

There is also the concept of an architect sync within SAFe at the large solution level. We encourage that ceremony to happen at the ART level as well, with the technical authority collaborating with technical leads or technical SMEs from various teams in order to drive technical collaboration. During this sync, you will all focus on the formation of that architecture runway and making sure there’s alignment surrounding how you and your team can make sure that you are fully enabled to deliver business value.

 

• • Preparing briefings

On the first day of PI Planning, you will have an opportunity to present technical guidance for the PI. This is where you can elaborate on those technical enablers that have been defined. There may be development practices, architectural guidance, and performance guidance. Technical information needed for the teams to plan is included in the briefing you will create to cover with the teams. You will provide context to everyone present on what needs to happen from a technical perspective.

 

Execution authority

As a refresher, the Execution Authority is the scaled up Release Train Engineer (RTE). Let’s take a look at their role:

 

• • Logistics and event coordination

There are a number of activities just to coordinate the event itself including:

• • • Making sure all presentations are prepared and aligned with each other
    • Determining where and how the event will be conducted, taking into account venue, food, and supplies for an in-person event, or technology and video conferencing needs for a virtual event.
    • Preparing a briefing to outline the breakout sessions, the process of communicating plans, when the Scrum of Scrums will be held, etc.

 

Learn about critical steps for RTE’s when conducting remote PI Planning 

• • Facilitation and risk resolution

As the Execution Authority, you are master of ceremonies, the overall facilitator of the PI Planning event. This would entail kicking off the session and covering the agenda. You will address any questions along the way and send the teams to their first breakout session.

 

The goal of the first breakout session in PI Planning is to get to a draft plan. During this time, your job is to make sure everyone is progressing towards that draft plan by paying attention and checking in on the teams often to:

• • • Provide support if teams are falling behind
    • Help the teams get unstuck
    • Help make sure the scrum masters are providing the right information

 

During the breakout session, the Execution Authority will also aim to help resolve all red sticky notes (which denote cross team dependencies of risks) that may negatively impact your execution. You would make sure that all risks are either resolved, owned, mitigated or accepted. The goal of the PI Planning session should be to walk out with none of those dependencies and risks outstanding.

 

At the end of day one, you will facilitate a ceremony typically with the business owner, product managers, architects, product owners and scrum masters in order to review scope changes and adjustments needed to get to a committed plan the next day. PI Planning is all about alignment!

 

Conclusion

These various roles are all key in ensuring the PI Planning event is a successful one. Now that you know more about how to get to a committed plan, stay tuned for the next installment of this series which will cover plan execution.