Making SAFe's® Program Increment Planning Event More Agile

April 15, 2014 — Posted by Al Shalloway

Plans are worthless, but planning is everything. Dwight D. Eisenhower

One of the more misunderstood aspects of SAFe is its Program Increment (PI)/release planning event.  To me, this is one of the most innovative aspects of SAFe.  Some misunderstand it and consider it to be a big batch up-front planning mechanism and then infer that the implementation of the plan is also based on big planning.  Both of these are misunderstandings, however.  Unfortunately, if one just focuses on the practices and forgets that above all, SAFe is a Lean-Agile based framework, SAFe can become ineffective.  It is critical to understand the intent of and principles underneath the planning event in order to keep it effective when things don't go as planned.  We must understand that the planning event is about doing pragmatic look ahead, fostering collaboration and creating a baseline for adaptation for a large organization.

PI/Release Planning

Let’s look at what happens in the planning event.  Teams within the release train (essentially all of the people in the value stream of the software being built) get together for two days to discuss the work they will be doing for the next 4-6 sprints. The output of these two days includes:

  • The planned backlogs for all but the last sprint (which is used for hardening, innovation and planning the next PI
  • The objectives for the PI
  • A list of dependencies between all of the teams
  • The list of features that will be implemented during the PI
  • A better understanding of when releases will occur

When one looks at these artifacts it’s not surprising that one thinks SAFe is just a big-batch, plan up front waterfall in Agile clothing.  But the difference between waterfall and the SAFe planning event, one works to the plan and the other uses the plan as a baseline to realize things aren’t working as planned.

The Mindset of SAFe® Implementation

I’ve already mentioned that SAFe is based on Lean principles.  But, first and foremost, SAFe is pragmatic.  This means that we do what works, while following Lean principles.  Clearly sticking to a plan – “because it’s the plan” doesn’t work.  The same could be said about the practices one uses to start any Agile endeavor (whether it be Scrum, Kanban or SAFe).  Pragmatism dictates that practices are how you start, but principles are what you use to adjust.

So the SAFe planning event is a start.  Sure, we’d like it to work. But we’ve all seen plans break down.  The fourth value of the Agile Manifesto is Responding to change over following a plan.”  Given SAFe is Scaled Agile Framework, this means that we must respond to reality when it deviates from our plan. In other words, we adjust our actions to the reality we now perceive in order to achieve the results we want to achieve.

The Results of the PI/Release Planning Event

All too many methods focus on the practices we use to start with.  But either when you run into challenges or you learn the basic skills of the method you want to start focusing on the results you want to achieve.  This moves us from prescriptive to guidance.   There is no reason Agile Release Trains (ARTs) can’t do this right from the beginning.  The results of the PI/Release planning event we want to achieve are::

  • Collaboration
  • Dependency identification
  • PI objectives (that is, what value we think we will be delivering throughout the PI timeframe)

Collaboration is within the teams, across the teams, and across management. Anyone who has not had the experience of a SAFe planning event has no real idea of the awesome collaboration that takes place.  I have seen this one event shift (at least temporarily) the ways an organization works.  The biggest shift is in how teams get to see that their management is committed to them because they are present throughout the event, helping them understand what is needed and lending their support to have them achieve it.

Working the Plan

SAFe is also based on Lean-flow, so let’s consider how a Lean-flow attitude would help us manage our PI after the planning event.  At a high level, Lean suggests we manage our work in three steps:

  1. Identify the most important work to be done (this includes finding that subset of our features which may be delivered early so as to achieve value delivered quickly)
  2. Allocate the right people/resources to the most important work and start working on it
  3. Use a pull system to manage the work flow from product managers/product owners to the team

The trick is to continue this through the PI. Essentially step 1 is a way to create effectiveness and steps 2 and 3 are about being more efficient.  The planning event is essentially steps 1 and 2.  Let’s walk through how this works.  After the planning event we will have the following sprint backlogs:

Figure 1: Sprint backlogs after planning event.


Now let’s take these sprint backlogs and have each team make one large product backlog as shown in Figure 2.

Figure 2: Combined sprint backlogs into 1 product backlog per team

Using Pull

At this point we can have each team pull from their backlog as normal Scrum would have them do. Note that if everything goes according to plan, we’ll just be working on the teams’ product backlogs in exactly the same way as a normal Scrum team.  However, this rarely happens, of course. Instead, some teams go faster and some teams go slower than anticipated. Each Sprint gives us an opportunity to track how we are doing on how our dependencies are unfolding.  They also give us a chance to check if our PI objectives are going to be met. 

Adjusting as Needed

So what do we do when things don’t go according to plan?  We adjust.  If a dependency isn’t going to be met in time we might have the teams involved work together more.  If an objective isn’t going to be met we can decide to either delay the release or we can see if we can cut some scope.  But either way, we can adjust.  We’re just now adjusting with a holistic view and basing our decisions on what is planned to be released.

What we shouldn’t do is:

  • Have people work overtime to make up the shortage
  • Figure we can use the Hardening, Innovation and Planning (HIP) sprint to make up for lost time
  • Make the teams wrong for not keeping their commitments

Shorter PIs Are Good in the Same Way Shorter Sprints Are

The planning event is to provide us the collaboration and big picture we need.  It is not meant to be big planning up front.  We often recommend to our clients to use 3 sprints plus a HIP sprint that can eventually be reduced to a week as the need for hardening is eliminated and the innovation gets integrated into the first three sprints.  This speeds up learning and enables organizations to eventually do two PIs per quarter.


The key to remember is the mindset from which you come in implementing SAFe.  If it isn’t Lean, you won’t implement SAFe in a Lean way.  If it is, you’ll manage to use the SAFe practices as a starting point for developing pragmatic Lean practices.  Use the planning event to get the collaboration, dependency identification and PI objectives.  Then use Lean to achieve as best you can.

Al Shalloway is an SPC Trainer, co-founder of the Lean-Systems Society (of which he is a current board member) and co-founder of Lean-Kanban University (no longer affiliated).

If you want to learn more about if SAFe® is right for you, check out our Leading SAFeM® with Net Objectives Extensions course.  You can also get a lot of information on SAFe® at our SAFe® Resources website.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban