Fixing PI Objectives

I get why SAFe’s PI Planning involves PI Objectives. Put simply, teams learn what value Product Management wants them to produce, they produce a lightweight plan for building that value, summarize their plan into a few objectives, and then translate the objectives into business speak. It’s just a simple alignment exercise, right?


I have yet to experience a smoothly run PI Objective exercise. This is not for lack of trying, or because it’s poorly explained or facilitated. Rather, I see a few systemic issues preventing it from going well:

  • Quantifying Business Value. SAFe asks the Business Owners (which SAFe defines as the people ultimately responsible for business outcomes) to quantify business value for every PI Objective. Using a scale of 1-10, the most valuable objective is given a 10, and the rest are assigned numbers relative to that. But no matter how this process is framed – and the intent is that the business value enables a prioritization conversation – teams always see the numbers as a judgement. For example, teams might say “We got dinged because our thing wasn’t as valuable as this other thing”. You’ll also see teams get demoralized when work they see as important is assigned a low number.
    This problem is particularly acute on distributed trains, where BOs can be in a different location than the teams.
  • Adjusting. It’s next to impossible to have the Business Value discussion early enough in PI Planning so that they teams can adjust to what they learned. The larger the train, the harder it is to get the BOs around to every team in a timely fashion.
  • Alignment. BOs and teams often don’t talk frequently, so they may need time to get on the same page about the work before they can talk about business values.

While there’s no silver bullet to solve these issues, let’s go back to the intent behind  objectives. These goals and numbers are meant to steer the direction of the train. For example, if a team’s #1 priority coming into PI Planning is working on a certain feature set, but they learn during the PI Objectives exercises that the BOs don’t see it as important as something else, that’s feedback the team can use to reprioritize their work. (And ask why they didn’t learn about this earlier!) The numbers also drive SAFe’s Program Predictability Metric, a way of measuring performance by value produced rather than process execution. Without some way of looking at how well the train builds and delivers value, it’s hard to get better at it!

Here are some experiments I’ve tried to make the PI Objective process more successful:

  • Define Business Value. Try asking people what “business value” is; you’ll find that most people define it differently. Help the team define it up front to avoid confusion down the road.
  • Facilitation. Actively facilitate the Business Value conversation so it stays focused on a crisp alignment on intended outcomes. This should help to avoid the common trap of getting distracted by technical details which, while important, are not the focus of this exercise.
    In addition, RTEs and coaches should frame this discussion as a respectful, two-way dialogue – not an audit!
  • Define the Business Owner group. Discussion around PI Objectives can be difficult to keep on track when the group of BOs grows beyond the minimum amount of people with deciding capabilities. Clearly defining a small BO group ahead of PI Planning – and letting everyone know who that group is – will make it run more smoothly.
  • Team Coaching. Teams often feel they need to “sell” their plans to the BOs. Work with your teams to clearly describe the value that they’re delivering rather than justifying their plan details.
    Note that this approach is especially important if teams are working on enablers – backend work that may not have immediate customer visibility.
  • Business Context Transparency. Not everyone in the room may have internalized their train’s business context. Giving teams continual access to the business context presentation – or, at a minimum, its major themes – during PI Planning can help teams write their PI Objectives in the business terms the BOs are expecting.
  • Early roaming. Encourage everyone to roam the room as early as possible. Business leaders in particular should learn as much as they can from the teams, continually asking and answering questions. The smoothest events are ones where leaders have a firm grasp of what the teams are doing early in the process.

PI Objectives can be a valuable tool for an Agile Release Train. With some tweaking of the process to accommodate the current maturity of your train, and coaching to encourage participants to approach the exercise as it’s intended, I believe we can help trains smoothly create useful PI Objectives. I’m sure there are other tweaks you’ve used; please share these in the comments!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s