Contact

Writing Good PI Objectives - Part One

Why do we need PI Objectives when we have Features?

A short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity.

The series will cover:

We have provided a PDF version of these articles, combining all of the content for offline working or study if required. You can download this here, or continue to scroll down this page to read part one in our series, and navigate each of the pages in turn, enjoy!

Download the set of full articles!



abstract

We have seen a lot of confusion surrounding the use of PI objectives; confusion that often results in:

  • resistance to their use and
  • the production of poorly formed team objectives that appear to be completely redundant as they just list the Features being addressed.

The first step to creating well-formed, useful objectives is for everyone to understand why they are so important.

why are pi objectives so important?

The purpose of PI planning is to generate alignment and allow teams to innovate, estimate and plan their own work.

PI Planning is part of SAFe®’s approach to ‘mission planning’ where, as in traditional mission planning:

The mission is a general statement of how you will achieve your vision. Strategies are a series of ways of using the mission to achieve the vision. Goals are statements of what needs to be accomplished to implement the strategy. Objectives are specific actions and timelines for achieving the goal.

We enter PI planning with a loosely defined set of goals that align to the previously considered business strategy (we shouldn’t have a room with 50 – 150 people ready to plan if we don’t have a strategy that their existence supports), and a prioritized set of Features that support, but do not guarantee, the achievement of the goals.

It is the job of the teams to come up with the objectives that embody the specific actions and timelines for the achievement of the goals.

why do we need pi objectives when we have features?

Now many people think that the role of the teams on a SAFe® Agile Release Train (ART) is to act as a software factory; mindlessly churning out the Features that have been selected by the Product Manager. This mindset is akin to the traditional waterfall mindset where the decisions about how to perform the mission and achieve the goals have already been determined by the great and the good.

For an Agile Release Train (ART) to be a high performing team of teams, the teams need to look beyond the Features and take ownership of the achievement of the goals themselves. This involves doing many things not found in, or even directly related to, the Feature list. If we want to have truly empowered agile teams then they need to be able to come up with their own objectives and not just select things from a pre-defined list.

Figure 1 illustrates the kind of things that ART’s need to consider, if not actively pursue, every PI.

Image of a variety of tasks that teams should consider for their agile release train (ART’s) actively for every SAFe or Scaled Agile Planning Increment PI.

Figure 1: Different Types of Objective

Figure 1 has four quarters that illustrate the different types of objectives that a team may pursue. On the right of the figure we can see a selection of objectives that provide direct value to the sponsors, customers and users by shipping Features or Stories, supporting business activities, answering customer queries or enabling business decisions. On the left of the figure we can see a selection of objectives that provide indirect value to the business by reducing costs, improving the way of working, eliminating waste, addressing risks, or improving the moral or knowledge of the teams. At the top of the figure we can see a selection of objectives that require development work and at the bottom a selection of objectives that require the team to do non-development activities. Product development teams need to do many more things than just developing and enhancing their products. The items are color coded in line with the SAFe® big picture and the standard PI planning instructions where:

  • Blue is used to indicate those directly related to Business Features and Business Stories
  • Dark Red to indicate those related to Enabler Features
  • Yellow to indicate those related to key events and milestones
  • Pink to indicate those generated by the need for the teams to collaborate, learn and relentlessly improve
  • Purple to indicate those related to the maintenance of the system

The positioning is illustrative only as the actual amounts of value and development work are context specific. The key points to note here are that:

  • There is truly no limit on the kinds of objectives a team can come up with. Those that represent the completion of Features only cover one part of a healthy team’s responsibilities.
  • An over-emphasis on Features as objectives stifles the autonomy and creativeness of the teams. If all they do is deliver the Features requested, they will become dysfunctional and create a legacy of technical, intellectual and motivational debt.

The goals of a team’s objectives are many including:

  • Clarify anything of importance that the team believes it will achieve within the PI
  • Record the team’s commitments
  • Bridge the gap between the team’s plans and the business’s goals
  • Ensure a balance between delivery and sustainability
  • Relentlessly improve
  • Continuously innovate, experiment and build knowledge

They articulate the specific achievements each team is going to contribute to the shared goals of the train.

the relationship of pi objectives to features: clarifying the benefits hypothesis

There is another important thing to remember when considering the relationship between Features and PI Objectives: Features are assertions and hypotheses not formal requirements. They are asks and not tells – pseudo goals and not agreed objectives.

The true relationship between a Feature and the PI Objective that a team creates when committing to deliver a Feature (or set of Features) is one of qualifying how the team intends to validate / prove / challenge the Feature’s Benefits Hypothesis. They do this by clearly stating the measurable results that their implementation will generate.

The team’s PI Objectives should qualify the benefits hypothesis of the Features they have selected and provide details of the real measures that they will use to do this.

Note: Teams that take on a Feature and quickly disprove the benefits hypothesis deserve full credit for their work and should score highly when the PI Objective is assessed at the end of the PI. We’ll talk more about assigning ‘business value’ to PI Objectives in the third article in this series: “PI Objectives and the PI Planning Process”, and reviewing the completion of objectives in article 4: “PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments”

good objectives focus on describing the measurable results

Well written objectives describe both the purpose of the actions being taken and the evidence that will be used to assess that the actions have been successful.

One very popular form of writing objectives in this style is the Objective Key Result (OKR) format popularized by Google.

This can be presented informally as a simple statement such as:

Objective: Provide an API to allow items to be added to the shopping cart by the end of Sprint 1 so that team Alpha can allow the results of their searches to be purchased. Key Results: The Shopping cart is successfully integrated with the search and browse functions allowing individual items, or sets of items, to be added.

Or using more tabular formats.

Objective For By Key Results
Provide an API to allow items to be added to the shopping cart so that the results of the searches can be purchased. Team Alpha End of Sprint 1 The Shopping cart is successfully integrated with the search and browse functions allowing individual items, or sets of items, to be added.
Update: September 2022
Scaled Agile have updated their guidance on Applying OKRs in the Scaled Agile Framework.
 
Their advice is don’t utilise OKRs for PI Objectives; keep it as a simple SMART statement. Their reasoning is that OKRs are intended to represent long term strategic goals. It takes a significant amount of time to discuss and negotiate such long term strategic goals and there should be 2-5 key results measuring progress towards the objective. Such overhead isn’t warranted for short-term PI Objectives.
 
When the blog series was initially written the use of OKRs was intended in a very lightweight fashion. The format of OKRs is used with just a single result in order to focus the team on ensuring that PI Objective is measurable.

Regardless of the formality of the presentation it is important that each objective clearly describes its purpose, any applicable anchors or constraints (such as when it is needed and who needs it), and finally the evidence (in the form of actionable, measurable results) that will be used to assess how well the team has done in achieving (or surpassing) it. In the next article in this series we will look in more depth at how to write well-formed PI Objectives before moving on to look at how objectives emerge from the PI Planning process and, finally, how to use the PI Objectives during the PI itself.

next… writing good pi objectives

In the second part of this series we’ll look at some of the practicalities associated with Writing good PI Objectives and how the writing process itself is iterative.




or

More Great Agile Content from Ivar Jacobson International:






Contact Us