The Role of PI Objectives
By Eric Willeke, SAFe Fellow, SPCT, Elevate.to
Note: This article is part of the Community Contributions series, which provides additional points of view and guidance based on the experiences and opinions of the extended SAFe community of experts.
Introduction
The role of PI Objectives is often misunderstood by teams new to PI Planning. They struggle at first to understand the difference between Team PI objectives and Features. SAFe does not provide a lot of guidance on the intent behind the usage of PI Objectives, and they are often misunderstood or misinterpreted. However, in my field practice, I’ve come to really value them, so I wanted to take the time to document my perspective in this article.
The main qualities of PI Objectives that I have come to value are their ability to:
- Validate understanding of the intent
- Focus alignment on outcomes rather than process
- Summarize data into meaningful and steerable information
Without understanding the above qualities, it’s quite easy to view PI objectives as nothing more than a shorthand list of Features to be delivered.
Validate Understanding of Intent
Two of SAFe’s four core values are Program Execution and Alignment, and one of the key Lean principles underlying SAFe is decentralized decision-making. Most of the PI Planning event agenda is focused on supporting these values by conveying a clear understanding of the desired goals and outcomes for the Agile Release Train, then getting out of the way and enabling practitioners to achieve these goals effectively. We place governing structures and other feedback loops into play through the product manager and Product Owner roles, but we generally support the teams’ ownership of the details in pursuit of the larger business outcomes.
However, one of the key risks that have plagued every software development approach is ensuring that the initial intent (scope) was clearly understood and articulated by the stakeholder, transmitted effectively to the development team, and interpreted in the same way. In SAFe, this path also includes the extra steps of translating from the end users to the Business Owner (who requires this capability), then onward to the product manager (for the release train implementing the capability.)
SAFe’s use of PI Objectives provides a unique tool to create an immediate feedback loop from the teams back to the Business Owners, allowing a quick validation of the teams’ grasp of the desired outcomes. In short, we give the teams the following challenge:
“Can you concisely convey, in words the business owner understands, the essence of the value sought by implementing this set of features?”
If a team cannot do this in a clear way by the end of planning, are we comfortable investing over $100,000 to pursue these goals over the next 10 weeks? By forcing the teams to summarize the intent and the outcomes they believe the Business Owner wants to achieve, we close the loop of understanding and drive crucial conversations that expose these misunderstandings. This, in turn, enables a much tighter form of alignment that transcends the written language of the feature to be amplified by the tacit understanding gained between the team and the Business Owner.
Focus on Outcomes Rather than Process
The second hidden value of PI Objectives is that they help the team shift focus off the feature language and onto the desired business outcomes. Features and acceptance criteria are amazing tools to help understand, capture, and collaborate around the work that needs to be done to iterate our solution to the next level, but it’s all too easy to get caught up in “finishing the features” and missing the overall goals hiding inside of them. The core question becomes:
“Is our goal to complete the listed features, or is our goal to provide the outcomes desired by those features? In other words, if we
could provide the same value with half the amount of work, and without building all of the features, would this be acceptable?”
I’ve found that the language of features can frequently steer the team into overlooking creative, valid, and architecturally sound solutions because someone outside the team already provided a preconceived notion of how that value should be provided. The closer understanding of the intent offered by direct conversations with the Business Owner occasionally results in the teams offering new perspectives to the architects and product managers and quickly finding ways to apply their expertise more effectively.
Summarize Data into Steerable Information
Finally, there’s a simple “comprehension” aspect to PI Objectives that I find particularly valuable. I’ve come to accept that no large group will reliably read every item in a list if that list exceeds 5-7 items. Given that I see small trains with only four teams consistently take on 10 features per PI, and large trains that have taken on as many as 40, I assume nobody except the product manager reads every single feature carefully—and certainly, nobody outside the train has read every one. As a result, I deeply value the summary of intent that the Program PI Objectives provide, and the subsequent use of those objectives as a key for providing clear evidence of progress both within and beyond the train.
I strongly encourage teams to fully and transparently share the features they intend to complete, and their progress against them in a percent of a complete mindset. But I’ve also found it valuable to summarize the 5-7 key objectives per train and report on progress against those. This is especially true when you have four or more trains working against the same value stream, aggregating a shared system demo to a senior executive audience every two weeks. Quite simply, you need a more compact way to convey the same information to augment the quantitative reporting.
A Bit of Philosophy
As I captured these thoughts, I was reminded of a key difference between release trains, and it strongly impacts the degree of value placed on the “focus on outcomes,” above. I tend to see release trains fall to one of two extremes: Either they drive the vast majority of their work (85-95%) through portfolio epics, and reduce the autonomy of the trains; or they drive the vast majority of their work as features, and reserve epics for the 5-10% of work that truly cuts across trains. While I don’t view either of these approaches as fundamentally wrong, I do believe that we will see that a majority of companies solving the big “system of systems” engineering problems, encouraging a strongly epic-driven approach, will find that SAFe for Lean Software and Systems Engineering will be a more effective approach.
At the same time, I fundamentally believe that the mindset of epic-driven development is serving the same role for steering at the scale that ‘waterfalling iterations’ served for teams: it provides a way for organizations to avoid learning those crucial lessons about how to work together in ways we never had to in the past.
Last update: 5 May 2020
