4 min read

Pragmatic Tips for SAFe® PI Planning, Part 2: Processes

Bonnie Beyer
Bonnie Beyer
16 January 2020 Agile
Pragmatic Tips for SAFe® PI Planning, Part 2: Processes

Pragmatic Tips for SAFe® PI Planning, Part 2: Processes

Program Increment (PI) Planning in SAFe® is a challenging exercise that requires considerable investment, but as mentioned in Part 1 of this 3-part blog series, it's an absolutely crucial activity for collaborative planning to be successful.

PI Planning is the hallmark ceremony for the organisation that adopts the Scaled Agile Framework for Enterprise®, taking place over two working days, and setting the direction for development for the coming Program Increment (usually defined as a fiscal quarter).

In my previous post I shared some tips to help you be more successful in the 'people' aspects of the PI Planning ceremony. Here in part 2, I'll cover some best practices on the process side. As before, the pragmatic advice here has come to light from my years of doing PI Planning, and from collaborating with other practitioners for their perspectives.

If you'd like to jump around, you can find Part 3 in this series, focussing on tools, here. Let's dive into three big points on the processes aspect of PI Planning:

Don't fear Shu Ha Ri

The Japanese concept for learning, Shu Ha Ri, when applied to SAFe® means initially following the guidelines 100% in order to become proficient. Once that's been achieved, you can adjust your techniques for what works best for your organisation. The final step is to innovate in your practice for continuous improvement.

After your team has performed PI planning a few times, don't be afraid to adjust things for what makes the most sense within the context of your organisation.

  • Does everyone really need to be there? Definitely yes in the beginning, but you may find that it isn't feasible or beneficial as time goes on. Work to find the right balance, but be careful to make sure all of the subject matter experts (SMEs) are there to identify hidden scope and dependencies. It's a major pain to have to replan after PI planning is over because your IT infrastructure expert laughed at your optimism!
  • How much pre-planning should be completed prior to the PI event? This is more an art than a science. You shouldn't wait for the PI event itself to collaborate on planned features, but be prepared to adjust when new information is introduced at PI planning.

safe pi planning support

Leaders: have all your ducks in a row

A lot of organisations make the decision to move to SAFe®, and then assign a specific individual or team to make it happen. Creating an Agile Center of Excellence or the like can be really valuable and important for the organisation as a whole.

However, such individuals or groups aren't going to be experts on your Agile Release Train's (ART's) unique product developments, processes, and culture. The ART leadership needs to make sure they are truly prepared for guiding their team members through the PI planning and implementation.

  • How is the scope allocated to epics and features? Make sure the people writing them have a common understanding for sizing, scope definition, and definition of done. Otherwise teams working on the features will have changing expectations from feature to feature and PI to PI, causing dissatisfaction and churn.
  • If everything is a priority, nothing is a priority. Make sure you prioritise features in a clear and sensible way, without spreading the teams so thin that nothing will actually get completed.
  • Provide clearly-prepared roles and responsibilities. New RTE, PM, PO, and SM roles and responsibilities are defined at a fairly high level in SAFe® guidance. With this there will often be misunderstandings and even hurt feelings between team members about how it applies to the detailed activities your organisation is responsible for day-to-day. The more clarity you can add here, the better – RACI is a good model for this.

Don't just identify problems, take action on them

Most Agile practitioners recognise that Agile will shine a spotlight on problem areas like inadequate staffing, single point failures, or bad requirements. Agile didn't create the problems, but just made them more visible. SAFe®, in a similar way, shines light on organisational problems.

  • When you look at the dependencies on a large program board, if you see a massive spider web, it may be time to reevaluate the organisation structure.
  • Similarly, if you see a large number of dependencies on a single team, it might be time to hire more people to help add depth in critical skill areas.
  • Identifying problem areas is not enough. If you don't take action to address those issues, you are missing a big opportunity for continuous improvement. If it's something that can't be solved during the PI event, assign an action item to a specific individual and hold them accountable for it at the next PI.

A bit of process focus can go a long way to a successful ceremony

Proper PI Planning requires good preparation up front, good actionable plans as take-aways, and the ability to adapt throughout. Keep these tips in mind, and the success of your event will show not just at the planning event itself, but in the execution and delivery of the scope throughout the PI. Isn't that whole point, after all?


Adaptavist provides expert consulting services around SAFe® and other practices that help increase agility in organisations.

Learn more about SAFe®


About the author: Bonnie Beyer is a Senior Transformation Consultant at Adaptavist. She delivers services around culture, processes, and tools to foster clients' transformation initiatives. She believes that there are no one-size-fits-all solutions, and works side-by-side with clients to understand their unique values and identify the solution that will work best for them.

Bonnie has 25 years of development experience, including seven years in agile transformation in a complex, high integrity systems company. She holds an MBA from the University of Iowa, an MS in engineering from University of Illinois, and BS degrees in engineering and mathematics from Washington University in St. Louis and Lindenwood University.