To BV or not BV?

Or "Is there value in assigning Business Value to PI Objectives?"

Dec 14, 2021

Every now and again you start a discussion with fellow Agile coaches and find that there are widely differing opinions about what makes sense. This happened to me recently. The subject was SAFe's practice of assigning Business Value (BV) to PI Objectives as part of the PI Planning event, and the subsequent assessment of the actual Business Value as the ART completes work.

Reactions from "I never coach PI Objectives, or Business Value because it doesn't add value" to "the 1-10 scale makes no sense for a Business Value assessment" to "PI Objectives make sense; Business Value not so much", and "I've seen Business Value assessment work well", and so on.

To BV or not BV?

Now by way of context, the coaches I am talking with are all very experienced coaches, having worked with many organizations on their move to Agile, and particularly Agile at Scale. The conversation is not the result of a lack of knowledge or experience but rather based on a keen understanding of both the purpose of the practice, the why, and the organizational dynamics in which it will be applied.

So to review, the reason that SAFe suggests the practice of both PI Objectives and the assignment of Business Value is to:

PI Planning
  1. Ensure there is a feedback loop as a result of the PI Planning event between what was requested from the business, and what has been planned by the teams.
  2. Enable local decision-making by the teams when they are faced with conflicting priorities based on the established understanding of business priorities.
  3. As a side effect, enable the creation of "Business Value delivered" predictability measure.

My experience has been that you can use both PI Objectives and Business Value assessment effectively. But I've also seen the practice get in the way of progressing true change or, worse still, seen organizations simply go through the motions, with no collaboration or feedback.

I suspect that this in the end is the root cause of the different perspectives. I've seen the practice used very effectively. For example, I attended a PI System Demo recently and, as they went through the demonstrations, the Business Owner really closed the feedback loop by talking about what the original PI Objective's expectation was, what happened in the meantime, and what the resultant effect was. She was clear about how we were all in this together and took pains to stress where the Program troika and the management team had contributed to (especially) less than expected results. The resultant actual Business Value assessment made sense.

But if this is not happening, then you should not force the practice. What this means is that you will need to revisit the purpose of the practice, and determine how you will get the same outcome if you do not use this particular part of the framework. For example, can the organization agree that the feedback loop is based on features being delivered and what does it mean if we do this? Can we evaluate the predictability of Business Value delivered through more direct means, such as a result of the telemetry of released product? Should we use PI Objectives without assigning Business Value so we can establish this important feedback loop? And so on.

Like all changes that affect the organization, context matters. And sometimes even experienced coaches will have to agree to disagree.

Need additional help?

PI Planning can get messy! If you find yourself in a bind, then drop us a line. We'd love to help you with your PI Planning. Let us know your concerns, and we'll set up a consultation with an experienced SPC in your industry.

Read more about PI Planning on our Blog:

5 Things to Know Before Your First PI Planning

The Synergistic Nature of PI Objectives

Pitching PI Objectives to the Sharks

Written by Hans Samios

For the last 12 years, Hans has focused on building sustainable improvements in organizational effectiveness through large-scale Agile Transformations. Leveraging his deep knowledge of Agile, Scrum, Lean, XP, and SAFe, Hans applies a pragmatic, team-oriented approach to coaching customers through optimizing the entire delivery process from concept to cash. His domain experience spans technology, IT, energy, banking, and insurance, but Hans also relishes applying Agile principles to non-traditional spaces such as marketing, construction, finance, and HR.