Establish the feedback loop with PI Objectives

In the Scaled Agile Framework (SAFe) the „PI Objectives“ are a summary of what an Agile Team (Team PI Objectives) and what all the Teams together as the Agile Release Train (Program PI Objectives) intend to achieve in the next Program Increment (same is true for the further aggregation of PI Objectives for the Solution Train).

The PI Objectives are a key element to create alignment on what the really important stuff is we need to focus on. They help to create a shared understanding of what Business Value means to the business and by which outcomes it can be realized for the ART in the Program Increment.

They are written and agreed on in the PI Planning (including the assignment of „Business Value“) and tracked during PI Execution. They finally close the feedback loop for the PI at the System Demo when planned and delivered outcomes are compared and we get a better understanding of the level of predictability we have reached. 

They are of such high importance that they are so-called „first-class citizens“ and are prominently displayed on the SAFe Big Picture.

PI Objectives provide a way to work goal-oriented and check understanding, however often they are not used at all. Why is that and what is missing when you don’t use PI Objectives? 

Scrum Sprint Goals

Very early in the history of Scrum, the concept of a team having clear goals and trying everything to meet these goals was a key idea the inventors and early adopters of Scrum emphasized again and again. Still, the practice of defining Sprint Goals is still being ignored by a lot of Scrum teams while the importance of defining and following goals is more and more emphasized in the recent iterations of the Scrum Guide where it is stated that the Sprint Backlog includes selected backlog items plus a plan to deliver the product increment and realize the Sprint Goal. The backlog items are just there to make the work visible required to realize the Sprint Goal. While most Scrum Teams learn that with the Sprint Planning the Sprint Backlog gets logged-in, this is not what is stated in the Scrum Guide (https://scrumguides.org/scrum-guide.html). In the guide, it is clearly stated that the Sprint Backlog may emerge during the Sprint as the Team learns more about how to achieve the Sprint Goals.

To put it in a clear way: It’s meeting the Sprint Goals that count not mechanically delivering the set of backlog items (often „User Stories“) with their Acceptance Criteria and DOD!

„A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint.“

http://www.romanpichler.com/blog/effective-sprint-goals/

Creating Effective Sprint Goals

Many SAFe implementations underuse PI Objectives

In Scrum, the Sprint Goals define an important focus point where all value delivered, progress and all effort spent is measured against and a way which is used to create alignment in the Team and between the Team and all the stakeholders. In SAFe the concept of Iteration Goals has the same purpose for the Team and the Iteration.

Take this concept and scale it up and you will end up with something like PI Objectives as described in SAFe. 

While the problem of not working „goal oriented“ is present in most Scrum implementation the same is true for many Scaled Agile Framework (SAFe) implementations. In most Agile Release Trains (ARTs) the PI Objectives are constantly underused and often there is a strong resistance to use them at all as „we do have the Features and Stories we need to deliver“.

Looking at the official training material on this topic it becomes clear that there is not enough guidance on how to write and use PI Objectives in a productive, value-generating manner. While it is clearly communicated that in the standard PI Objectives belong to the expected results of a PI Planning event the examples displayed in the official SAFe 4.5 training material may even point you in the wrong direction on how to do it (IMHO got much better in the SAFe 4.6 material).

Some additional guidance for PI Objectives

Beside the guidance article found on the official SAFe site there are some additional articles and presentations available describing the importance of PI Objectives in a different way and giving better guidance on writing and using them.

The Role of PI Objectives

In this advanced topic guidance article for SAFe Fellow Eric Willeke summarizes the role of PI Objectives. We will refer to this article later in more detail…

The Synergistic Nature of PI Objectives

Charlene Cuenca give a good overview of the role and importance of PI Objectives in this presentation she gave at the Global SAFe Summit 2018 in Washington.

Measuring Business Value

This presentation (also Global SAFe Summit 2018) by Drew Jemilo & Jennifer Fawcett contains an explanation of how to write better PI Objectives and how to assign Business Value in the PI Planning. The slides explaining the concept and application of PI Objectives are very valuable and many readers like this approach more than the SAFe 4.5 training material. The talk is available on video.

What are good PI Objectives?

PI Objectives are one of the results of a PI Planning event in which we were able to agree on some shared goals (outcomes) that the Teams / the full ART should deliver in the next Program Increment. Teams in the ART commit to doing everything in their power to deliver their Team PI Objectives or make it immediate transparent when a PI Objective is at risk.

The objectives are written in a common language and understandable by the other Teams, the Stakeholders and Business Owners. They might be connected to a specific milestone like a tradeshow, maybe an aggregation of Features or a combination of different elements.

Most important is that benefits and value are clearly understandable and connected to the overall goal and the strategy of the organization and the ART which means a PI Objective may reflect directly business goals or might emphasize important enablers (gaining information, investing into technology).
Therefore the PI Objectives are describing what value is going to be produced by the Agile Release Train and as such supporting the primary principle of the Agile Manifesto:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

https://agilemanifesto.org/principles.html

PI Objectives do not need to map directly to Features in the Backlog but they sometimes might be a very important Feature or an aggregation of Features where the aggregation as such makes sense from a business perspective – which is not „Deliver Feature 1-3“ but something like „Initial autonomous parking capability in standard parking lots type 1“ (which probably includes functionality specified in Features 1-3).

By agreeing on the objectives of the whole ART including its Stakeholders are aligned to a shared mission, everybody knows what are the goals for the next Program Increment. This helps to decentralize decision-making and usually improves the flow of value.

What benefits will you get if you use PI Objectives correctly?

Using PI Objectives helps to establish a culture of goal orientation instead of task orientation and with that focus on outcome instead of output. Used in the right way, a very valuable feedback loop with a lot of communication and collaboration between Business and Dev is created which creates high transparency and full alignment. This is important for building trust between Business and Dev and created real ownership & commitment on both sides.

Good PI Objectives provide the following benefits:

PI Objectives establish a critical feedback loop & foster collaboration between Development and Business

In his article „The role of PI Objectives“ SAFe Fellow Eric Willeke explains the following aspects of PI Objectives in more detail:

• Validate understanding of the intent 
• Focus alignment on outcomes rather than process 
• Summarize data into meaningful and steerable information

Let’s have a closer look on how the feedback loop is established between Business and Development:

1. Business and Product Management state at the beginning of the PI Planning the enterprise strategy, enterprise context, the business goals and the product vision for the next PI. While there should be an ongoing communication about these aspects during the PI Execution, everybody in the ART gets an updated clear understanding what the mission for the next PI is.
2. The Teams take the prepared and discussed Features related to these business and technical goals and start figuring out a way how to deliver a maximum of value to their enterprise. They do this by breaking Features down to smaller chunks of work, typically User Stories, which they check for dependencies and other constraints. Then these smaller chunks of work are planned to be developed in a specific Iteration where enough capacity is available. While this might change during PI Execution it’s their base plan on how to implement work items that contribute to delivering Business Value to their enterprise. They finally summarize all the goals they want to achieve in (Team) PI Objectives and Stretch Objectives.
3. Later in the PI Planning the Teams explain their plan using the PI Objectives and the Business Owners understand what Development will do and rates that in „Business Attractiveness“ (Business Value). This is typically a highly collaborative process where the teams explain and refine the PI Objectives and the Business Owners understand the constraints and alternatives identified by the team. Development gets better in understanding which elements are delivering value, Business understands better what is possible with the given constraints (capacity, expertise, ..). This is a core element in bridging the gap between Business and Dev and for building trust. This is part of the feedback loop in the PI Planning and critical for the collaboration and alignment between Business and Development in planning and executing the PI.
4. An agreement is found how maximum Business Value can be delivered with the given constraints. The PI Objectives then become the business summaries of what outcomes each team intends to realize in the upcoming PI.

With all this it become clear that working with PI Objectives is a key element in SAFe as it creates transparency and alignment in a highly collaborative way. The whole organization focuses on outcomes (create business value) instead of output (deliver specific Stories / Features in a specific Iteration).

Note: This text was drafted quite some time ago and the idea was to create a series of articles about the PI Objectives. I never had the time/focus to do that but while it might not be perfectly written I see some value in publishing it now. Feel free to comment.