The idea behind SAFe's PI Planning

One of the key ceremonies in SAFe is the "PI Planning", where teams come up with an aligned plan for the next 6 iterations. Why do we have this special ceremony?


Let's start with the reason why SAFe's PI Planning has been designed, and what happens during PI Planning:

1. We don't plan for others. The teams create their own plan. Handovers are discouraged.
2. We don't plan activity. We plan objectives. This provides enough transparency for everyone. 
3. We don't schedule the details. We sort the objectives in descending value order, then put the most valuable thing first.
4. We don't focus on having a plan. We focus on achieving a common understanding. Unexpected things happen and our estimates are usually misleading. That shouldn't stop us from having a thorough discussion about what, why and when.

Objectives over Stories

More important than defining the individual backlog items (i.e. user stories) is the definition of mutually agreed upon objectives, i.e. what the teams desire to accomplish - and why their work contributes to the enterprise goals. 

While stories are created for features during PI planning, the main purpose of stories is to discover the scope, range and purpose of the feature in collaboration within the teams, with Product Management - and Business Stakeholders!

The Stories that are created are then summed up in terms of objectives, i.e. outcomes that the teams want to obtain. The value of these objectives is discussed in business terms, with the intention that developers have a clear understanding of why certain goals are more valuable than others.

This shared understanding of common goals is probably the most important output of the PI Planning, because it keeps expectations closely aligned in the following months.

Catch inconsistencies

When teams place their objectives on the Program Board, this forces them to consider whether their objectives are consistent: within themselves, with each other, with those of other teams, with time available, with extrinsic factors (such as: market constraints, vendor delivery etc.). With simple red strings, the Program Board shows dependencies - which themselves are pointers to a high risk of becoming inconsistent.

The visualization of planning inconsistencies helps teams to steer clear the pitfall of inconsistent delivery later on. 

While a part of the purpose created by the program board is indeed to get a clear understanding of what will be done roughly when - the biggest value is to have a consistent big picture, shared by everyone on the Release Train!

Planning horizon

A big question for many agilists is: "Why do you plan 3 months ahead?" - This has mostly to do with U-Curve optimization. 

We don't do this because we consider it's a good idea, it's more likely the most feasible thing to do, especially in environments with distributed teams. Our goal is to minimize batch size. 

For an organization that is currently transitioning from a legacy development model that has a more-or-less expressed backlog for the next couple years, moving from a "We just do what we feel needs to be done" towards "We know exactly why this thing is Priority 1 and how we can contribute" is a massive leap forward.

Think ahead

The 3-month planning horizon creates a slowly depleting team-levelbacklog for each team. Based on the one central product backlog, every team backlog has been clearly optimized to maximize the value this team delivers. When a team fails to meet their objectives, they have a clear understanding of the value gap - and can use this to communicate with other teams to maximize overall value delivery in a delivery Inspect+Adapt.

The team backlogs are not exhaustive. They contain value-ordered lists of those stories that are known upfront. The teams still refine their backlog continuously throughout the PI. Items from the backlog may be added or removed as new information becomes available. 

The defined PI Objectives help the teams place new items into an appropriate position in the backlog and provide a useful guideline for value delivery. Within the scope of the defined objectives, the teams gain full autonomy on how to build things without the need for frequent synchronization and coordination meetings.

Optimizing PI Planning

There are two questions we should ask about the PI Planning horizon:

1. How can we reduce the overhead associated with planning - so that we can plan together more often?
2. How much value do we lose by having to resort to mid-term planning - and what can we do to decrease the value decay?

If you can get all the teams to plan together every month or even every Sprint, then by all means - do that! The planning periods will be shorter, product value will be higher and mutual understanding will be better.

Summary

SAFe's PI Planning is the first step in an evolution away from Big Upfront Planning, with the intention that teams gain full control over their work, while providing the required stability for effective, valuable collaboration. 

As your organization becomes more agile, PI's might become more fluent and iterations shorter. As mutual understanding grows, the need for clarification will decrease. Plannings become smoother and faster over time. 

As you learn how you can maximize the value of planning, the nature of your PI Planning will adapt accordingly.

What will remain is the need to have a common understanding by planning together frequently.