4 min read

Pragmatic Tips for SAFe® PI Planning, Part 3: Tools

Bonnie Beyer
Bonnie Beyer
30 January 2020 Agile
Pragmatic Tips for SAFe® PI Planning, Part 3: Tools

Pragmatic Tips for SAFe® PI Planning, Part 3: Tools

For organisations that adopt the Scaled Agile Framework for Enterprise® (SAFe®), there is no single ceremony that's more important than PI Planning. Most often held over two business days, it sets the direction for the coming Program Increment (PI), which typically encompasses a fiscal quarter.

PI Planning is challenging mentally, can even be challenging emotionally, and requires a big lift in terms of time and effort. But as we examined in Part 1: People and Part 2: Process of this blog series, good practice can help avoid many of the pitfalls and lead to a more successful outcome for all involved.

In this third and final episode, I'll share more advice gleaned from interviews with SAFe® practitioners and from my years of doing PI Planning. This time we'll examine the 'tools' aspects of a successful PI Planning event.

Tools are meant to make it easier, not harder

If your teams are struggling with the tools so much that they don't have enough time to break down scope, collaborate on dependencies with other teams, and identify their risks, then maybe the tools need to be changed.

Perhaps you need a full overhaul to modernise your toolset. Or maybe you've moved to modern tools, but there are gaps in the functionality you need (such as roadmaps and dependencies, just to name two).

  • If team members aren't trained on the tools or are struggling with them for other reasons, let them use paper. Remember the goal for the PI event. Sticky note planning is still a valid method for capturing the thoughts of the host of smart people in the room contributing to the PI Planning event.
  • Identify the toolset gaps and talk to some experts, either from within your organisation or from outside of it (like us). Don't settle for using hammers that cause swollen thumbs.

safe pi planning tools growth

Logistics matter

The first two levels of Maslow's hierarchy of human needs are Physiological and Safety. If the people are hungry and freezing, or they don't feel safe, they are not going to do their best work. Make sure you take all of these things into consideration with the logistics.

  • Make sure there is good wifi and/or plenty of hotspots available. Big monitors for teams to use for planning are really helpful too. Consider all of the diet restrictions and preferences for the people that will attend the PI Planning event.
  • An off-site location is best, but if it is just a single big room, it's going to get noisy. Try to find a place with break-out rooms available, or one that's large enough to have plenty of space between tables – preferably also with central heat/air and good janitorial staff!

Jira tells you what happened, but not why

Jira is great at giving you "just the facts, ma'am." It has excellent reports and dashboard capabilities, and the add-on apps that are available in the Atlassian Marketplace can give you metrics galore. But it is important to remember that the metrics don't tell the whole story. What happened and why it happened are two separate things.

  • Your team velocity last sprint tanked. Why?
    Well, Randy was overworked and came into the office with Influenza A, and so the whole team caught it. The solution is to foster a culture that prioritises health and taking care of yourself when you are sick.
  • The Program Increment features that were planned didn't get completed. And some of the work that did get completed wasn't scheduled for this increment. Why?
    IT finally released the resources that we had been requesting for the last nine months, so it was use-it-or-lose-it. If shifting budgets or priorities cause plans to change, the remedy is to document and communicate the reasoning as soon as possible so it's clear to all stakeholders.
  • The team was incredibly successful with implementing a very demanding set of features last quarter. Why? Maybe we aren't giving them enough work?
    No! They worked their butts off to make that initiative successful. We need to reward them and not simply overload them again.


Raise your ELMO!

Even though 2 full days of PI planning can seem like plenty of time, there is a lot of work to be completed, and it can be challenging to finish everything. Don't be afraid to throw the ELMO card: "Enough, Let's Move On!"

We all have been in meetings where people go down a rabbit hole in their discussions. Heck, I've done it myself (and most likely so have you).

  • We can continue to clarify a point we're making. We can continue to focus on a small piece of design that doesn't impact the broader group. We can even continue to waste time discussing a problem that we can't solve right now with the people who are present. OR we can raise the ELMO and say "Let's get back to the agenda."
  • I've seen printed Elmo cartoons on sticks at PI Planning tables that people would wave in the air – yes, really. These are actually great, because you don't have to look for an opening to interrupt the conversation. If you didn't have them in your last PI event, I highly recommend bringing ELMO with you next time.

It's not about tools, it's about results

The real value of PI planning is the facilitation of all of the product contributors to plan development and identify dependencies together. I've heard time and time again how valuable it has been to get everyone in a room examining the work ahead, and bringing things to light that could have been serious schedule and cost pitfalls for their programs.

A successful PI plan's proof is in the results you see in more effective program delivery, and of course in delighted customers and end users. 

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.