AN IJI RESOURCE

WRITING GOOD PI OBJECTIVES

Setting the Pace in Software

Page 1

INTRODUCTION & ABSTRACT

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

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.

In this series we will cover:

1) Why do we need PI Objectives when we have Features?

2) Writing good PI Objectives

3) PI Objectives and the PI Planning Process

4) PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your

Commitments

Copyright (c) 2022 Ivar Jacobson International SA. All rights reserved. Except as specifically permitted herein, no portion of the
information in this document may be reproduced in any form or by any means without prior written permission from IJI.
Page 2

SECTION 1: WHY DO WE NEED PI

OBJECTIVES WHEN WE HAVE
FEATURES?

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 goal
Page 3

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.

The following illustrates the kind of things that ART’s need to consider, if not
actively pursue, every PI.
Page 4

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

Page 5

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
section in this document: “PI Objectives and the PI Planning Process”, and
reviewing the completion of objectives in section 4: “PI Objectives Beyond PI
Planning: Reaffirming and Monitoring Your Commitments”.
Page 6

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.
Page 7

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 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;

Page 8

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 section in this document 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.
Page 9

SECTION 2: WRITING GOOD PI

OBJECTIVES
GOOD OBJECTIVES FOCUS ON
DESCRIBING THE MEASURABLE
RESULTS
As we saw in the first section that it is essential that the objectives come from the
teams, this ensures buy-in, unleashes the creativity of the team members, and
helps create a better plan. It does though beg the question where do the teams
find the inspiration for their objectives?

We have found that there are 5 areas that every team should consider when
forming their objective, each of which can influence the phrasing used when
writing the objective itself:

Features - Generating value by delivering one or more Features.

The most obvious source of Objectives are the features that the team has taken.
In this case the Objectives should not simply be a re-stating of the Feature’s
name. They should capture the results of any negotiations that have occurred
during planning; the Feature request that came into planning is not necessarily
what ends up being done.

Example:

Objective: Provide “Flexible Search” with fuzzy character matching (see the
Flexible Search notes for details) that displays the results in a list ordered by
closest match.
Page 10

Collaborations - Helping other teams do Features.

Many features need inputs from several teams; the collaborations where one
team is helping another make good objectives. Indeed, the receiving team will
be listening out for the objectives from the other teams that have agreed to
deliver work or information to them.

Example:

Objective: Provide team Alpha with an API to allow items to be added to the
shopping cart by the end of Sprint 1 so that the results of searches can 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.

Not all collaborations are document or code handovers, sometimes they are true
collaborations, an architectural gathering to map out technical strategy for a
feature or future work.

Example:

Objective: Collaborate with team Alpha and System Architects on Wednesday

4th to establish the Shopping Cart API to allow items to be added to the
shopping cart for future purchase.

Key Results: API agreed. Stubbed functionality coded and submitted to version
control that allows both teams to develop, and test, in parallel.
Page 11

Internal work - Keeping the train running smoothly.

Refactoring, code clean-up, keeping the lights on, relentless improvement, and
much, much more are all things that the train needs to do but aren’t necessarily
coming through the Program Backlog.

Teams should be empowered to add work that they know they need to do to
their own backlogs; but this internally generated work must be made visible to
honour the principle of transparency and allow tracking and negotiation around
it. This internally generated work can be aggregated into one or more objectives.

Example:

Objective: Reorder the tests in the automated regression test systems to run the
end-to-end performance and smoke tests ahead of the repetition of the
functional Feature tests.

Key Results: Ability to determine a working build ahead of the detailed Feature
level validation so we can spot systemic failures faster and repair them quicker.
Page 12

Capacity Reservations - To deal with the known-unknowns.

These objectives occur when teams know that there is work to be done but they
don’t know exactly what that work is going to be until it appears; typically these
are operational incidents such as emergency defect fixes or support duties to
assist frontline staff. The team can set capacity aside to deal with this work and
honouring the principle of transparency it can be made visible by turning it into
an objective.

Note: In these cases it is essential that it is clear what the capacity is going to be
utilised for and to bound the amount of capacity that will be consumed. This can
then be tracked and the numbers used to influence the reservation in
subsequent PIs.

Example:

Objective: Provide frontline support to the call centres answering queries,

analysing problems, and providing work arounds and hot fixes as necessary.
Key Results: Support calls are dealt with within 12hrs. No more than 10% of the
team’s capacity within the PI is spent on support.

Learning and Growth - Gaining knowledge.

Whilst this could be considered Internal Work many organisations are striving
towards Enterprise Agility and one of the key cornerstones of Enterprise Agility is
to have a Learning Organisation. It therefore makes sense to explicitly ask all our
teams to be thinking about how they will learn and grow.

Without learning and growth there will be no improvements to how we develop

our solutions and the solutions themselves will be anchored by their historical
context and unable to change. It is important to make the learning objectives
visible so that we can demonstrate that the teams and the train are preparing
and evolving their skills ready for the future.
Page 13

Example:

Objective: Learn about non-Latin mark-up in HTML to prepare ourselves for the
content translation functionality that is on the roadmap for the next PI
Key Results: Demonstrate at least two pages using non-Latin character sets,
spending no more than 2 days of the team’s effort.

Writing Objectives - Make them SMART.

Objectives should be SMART. You’ve probably already encountered the SMART

acronym with respect to your own personal objectives, and it’s regularly
referenced in training material on writing objectives, but how does it apply
within SAFe’s PI Planning context?

Specific (simple, sensible, significant)

In the previous section we discussed The Relationship of PI Objectives to

Features: Clarifying the Benefits Hypothesis; the concrete instantiation of how
the team intends to approach the problem. This needs to be specific, clearly
stating the action and the intended outcome as concisely and explicitly as
possible.

As seen in the examples above we favour a two part format where part one
communicates the action and its purpose whilst part two clearly specifies the key
results.
Page 14

Look for key words such as:

Deliver
Provide
Improve
Learn
Decide
Support
Ensure
Prevent
Demonstrate
Investigate

We make the key results specific by making them measurable.

Measurable (meaningful, motivating)

In the previous section we discussed how Good Objectives focus on describing

the measurable results: Look for the evidence / results - is this clear and
measurable?

Has the team called out the key results that will prove they have achieved the
objective?

Watch out for “weasel” words, typically adjectives, that don’t mean anything
such as:

Better
Easier
Efficient
Faster
Quicker
Simpler
Page 15

All of these need some form of quantification in order for the objective to be
measurable, and some kind of target for the objective to be achievable.
For Quicker, have a target for how much Quicker you’re expecting to make the
system.

For Easier & Simpler, what are the specific concrete actions that are going to be
done to make the system Easier or Simpler.

The more concrete the target that is being aimed for the easier it will be to judge
and score later on when the feature has been delivered.

Beware: more concrete doesn’t mean we lock down our options; don’t form a
strict plan that cannot be deviated from! What it does mean is that we
understand how we are measuring the targets that we are setting for ourselves,
so that when we do evaluate options within the execution of the Program
Increment we know that they’re achieving the desired goals.

The measures may be descriptive, binary (yes/no), quantitative or provide a

range. However if the results are to be measured then they must be achievable.

Achievable (agreed, attainable)

As well as ensuring that key results themselves are achievable the team should
also be thinking about whether or not they are equipped to achieve them. Do
they the skills and capabilities needed? Is achieving the objective within the
team’s influence and control? For an objective to be achievable the team needs
the skills required to deliver the results; or the plan needs to contain time to
acquire those skills.

As well considering whether or not the team is equipped to achieve the objective
they also need to think about whether or not the objective itself is realistic,
relevant and reasonable.
Page 16

Realistic (relevant, reasonable)

The team should also be thinking about whether or not their plan to achieve the
objective is realistic. In fact before they start planning they should consider
whether or not it is realistic for them to take on the work - sometimes the
objectives themselves are not relevant or reasonable, and therefore not sensible
objectives for the team.

If the objective does not seem worthwhile, if we’re not the right people to do it or
it is clearly not the right time to take it on then, even though it is specific,
measurable and achievable, it is probably not a realistic objective.

For the achievement of the objective to be realistic the team also needs to have
set the right amount of time aside at the right time within the sprints to satisfy
any internal collaborations or external dependencies.

They also need to understand all the additional activities that they are expected
to perform in order to ensure that the work is done properly; this will be driven by
the Definitions-Of-Done at Story and Feature level.

The underlying plan for delivering the objective needs to be realistic, making any
assumptions and risks visible. The plan should deal with a reasonable “bad-day”
scenario; the estimates shouldn’t be too optimistic.

Recognize factors that cannot be controlled and avoid making “happy path”
assumptions. Plan to do everything; if things happen quicker, or a better solution
emerges that involves less effort, then execution gets easier and the team can
always pull work forward from Program Backlog or spend the gained time
clearing technical debt.

It must also be realistic to achieve the objective within the Program Increment. If
the objective is too grand in its scope then it may require more than one PI to
complete. This means it is not a realistic PI objective.
Page 17

Time-bound (timely, time sensitive, time/cost limited)

Within SAFe® the default time-bounding for a PI Objective is the timebox of the
PI itself; but some objectives might need to be more tightly time-bound. In
particular the collaborations where there is an agreement in place to deliver
something by a certain point in time; but don’t constrain yourself more than you
have to.

If it’s not explicitly needed by a certain date give yourself the freedom of
anywhere in the PI. Look for the anchors. Is the timeline fixed or flexible? Is there
a customer or collaborator that depends on the timely achievement of the
objective?

Sometimes the objective isn’t just time-bound by a fixed delivery date or a

specific time-box; sometimes you want to limit the amount of time that is to be
spent on attempting to achieve the objective. Often these kinds of time-limited
objectives are called Spikes - some of these may already be explicitly identified as
backlog items but many of them will emerge as the objectives themselves are
formed. Make sure that any time-limits are explicit in the objective.

SMARTER - going beyond SMART objectives.

Many authors, including Professor Rubin, have noted that the definition of the
SMART acronym may need updating to reflect the importance of efficacy and
feedback. To this end, some authors have expanded it to SMARTER to include
extra focus areas Evaluated and Reviewed.
Page 18

The good news here is that we don’t need to extend the acronym as these are
built into the SAFe® framework as part of both the PI planning process itself and
the PI’s Inspect and Adapt activities.
Page 19

SECTION 3: PI OBJECTIVES AND

THE PI PLANNING PROCESS
OBJECTIVE CREATION WITHIN PI
PLANNING
Objectives are not an input to the PI Planning process they’re the output; they
are created to describe where the team’s time and effort will be spent in the
upcoming PI.

Teams should try to avoid waterfalling the writing of Objectives; don’t leave it
until the very end! Write objectives up as you plot work into sprints and/or as
work is negotiated with other teams.

Teams should be applying the Lean and Agile principles to the act of planning
itself. Teams should be taking one feature at a time from the backlog and adding
it to their plan; but at the same time the teams should be deferring elaboration
of the detail until later.

In practice this means breadth not depth. Teams should put a rough plan
together early in the planning process and have a full set of candidate objectives
ready by the end of the first break-out even if they haven’t finished planning all of
them. This is so that the Business Owners can do a proper job of scoring the
objectives during the second break-out on Day 2.

The act of scoring the objectives will inevitably result in negotiations that will
change the details so better to defer elaboration of those details as late as
sensibly possible in the process to avoid effort being wasted on detail that
subsequently gets negotiated away.

With a rough plan assembled and candidate objectives laid out the team can
continue to add more detail; particularly focus on the early iterations as the detail
required for execution will be needed sooner than the later iterations.
Page 20

GETTING TO GOOD OBJECTIVES

Crafting the words for a good objective is itself an iterative process. In this
example we’ll look at the steps that a team have gone through to get to a good
objective and examine some of the thought processes that drove development
of the objective.

Accepta
Flexible Search nce Crit
eria
Feature: easy-to-u
se
Single f
Search
ield for
en tering s
h a ve a fl exible, for auth
o
earch te
rms.
er s w ill oo ks . M a r , tit le, or ge
Us
y t o lo c a te b tch algo
r ithm inc nr
pabilit e.
search ca mispell
ings in t ludes cl
os e
om a he resu
o r , t itle , or genre fr charact
e rs d if
lts, max
imum 4
a rc h b y a uth g Re s
ference
.
Se is sp ellin u lts displayed
rch field. M an...").
single sea "D id y ou m e match. in list b
y closes
u tio ns (i.e orithm. Resul t
su b stit -m atc h a lg ts gene
a s p a r ra
sults ted on s
Present re 200ms. erver w
ithin

The team have grabbed a feature called “Flexible Search” and have been
negotiating and planning it during a PI Planning event.

Their first attempt at an objective is: 'Provide Flexible Search'

Page 21

Essentially just a restating of the feature name; this is likely not specific enough
to capture any negotiations that have occurred during the planning event itself.

As a coach my questioning to the team will often start with “Are you planning to
do all of it?” Upon questioning the team reveal that scope negotiation has
occurred so the results of that negotiation get written into the objective:

'Provide Flexible Search with basic matching and a Levenshtein Distance

Algorithm.'

“Basic” is one of our trigger words; it’s not specific. The team need to rephrase
that to explain what their idea of “Basic” is;

'Provide Flexible Search with exact character matching and a Levenshtein

Distance Algorithm.'

'Levenshtein Distance Algorithm' is too specific; it locks the team into a specific
technical implementation. Whilst we want to be specific (from the SMART
acronym) about the business outcomes desired, it would be preferable to
preserve the design options available to the team during execution, following
SAFe® principle #3 (See also our SAFe Principles Cards for more detail on the
principles).

Flexibility in this dimension allows the team to explore other algorithms with the
aim of achieving a better business outcome. The specific technical phrasing is
also something that the stakeholders might struggle to understand. The team
are steered towards rephrasing this in terms of the outcome expected and using
language the stakeholders will understand.
Page 22

'Provide Flexible Search with exact character matching and fuzzy matching.'

Do we need to clarify any other assumptions that people might have? In this
instance is this just the back-end processing of the search or are the stakeholders
expecting to see the results listed?

'Provide Flexible Search with exact character matching and fuzzy matching
and display the results in a simple list.'

“Simple” is another trigger word; it’s not specific.

'Provide Flexible Search with exact character matching and fuzzy matching
and display the results in a list ordered by closest match.'

In this context “and” is another trigger word. Isn’t exact character matching just a
form of fuzzy character matching where all the characters match?

What do we mean by fuzzy character matching? In this case the team needs to
do two things: 1) include the Feature Card in their negotiations, and 2) start to
think about the key results that they are expecting.

By referring to the Feature Card they find that the level of fuzzy matching desired
has already been defined, and that there are already some negotiable
acceptance criteria that hint at the expected results. Using this information they
add more notes to the Feature Card and prepare their final revision of the
objective.

'Objective: Provide “Flexible Search” with fuzzy character matching (see the
Flexible Search notes for details) that displays the results in a list ordered by
closest match.'

'Key Results: The search allows users to find items that match and are close to
the given spelling.'

The journey to a good objective has captured the negotiations of planning,

ensured specificity whilst preserving flexibility and clarified any assumptions.

Page 23

UNCOMMITTED OBJECTIVES
Uncommitted objectives are used to indicate risk that an objective might not be
achievable; teams are not required to make a commitment to delivering their
uncommitted objectives. By having the escape valve of uncommitted objectives
the commitment to the main objective becomes stronger.

Some of the criteria for Uncommitted Objectives are:

The last feature in the last sprint of the team’s plan. If something goes wrong
and other features take longer to deliver then this feature is likely to be
knocked off the back of the plan for this Program Increment.

A feature with a significant external dependency where the external supplier

is notoriously bad at delivering on time. If the delivery was expected early in
the Program Increment and there is sufficient flexibility in the plan to move
things around if things slip then classing as a stretch might not be needed;
but if the delivery were towards the end of the Program Increment and leaves
very little room for manoeuvring then classing as stretch is a useful signifier.

Can the highest priority Feature from the backlog be an uncommitted

objective?

Yes. Use of uncommitted objectives is to indicate risk and if there is significant

delivery risk then it should be a stretch objective. If the stakeholders requesting
and prioritising the features don’t like that then encourage them to work with
the team to de-risk the delivery; the stakeholders may have more authority over
any external factors and can help the team.

Teams and stakeholders must learn to strike a balance and embrace some
degree of risk; only significant risks involved in delivery should be criteria for
classification as an Uncommitted Objective.
Page 24

SCORING OBJECTIVES
As part of the activities occurring during the Team Breakout Session on Day 2 the
Business Owners are asked to score the objectives. SAFe® uses the phrase
Business Value; but our preference is to use talk about importance to the
business rather than value.

There are three reasons for scoring the objectives:

Early Contact – Uncover the assumptions

Data Point for team sequencing
Closing the loop – Predictability to plan

Early Contact: Scoring the objectives forces the Business Owners to read and
understand the objectives; this will uncover any assumptions that either the
team has around what the business wanted or assumption the business has
around what the team is expecting to deliver.
Page 25

Team Sequencing: The team’s goal is to try and maximise the amount that
they’re delivering back to the wider organization; they should try to target the
most important objectives and the scoring provides that information. Ultimately
at the team level technical issues will primarily drive the sequence in which
stories are accomplished; the team might need to go through some less
important objectives to unlock the ability to deliver the more important
objectives.

If bad things happen then the team also knows which objectives are most
important to the business and can focus on them and defer the less important
objectives.

Closing The Loop: The score will be used to close the loop on predictability of the
team’s delivery of the plan. Closing the loop will be covered later in this
document.
Page 26

COMMUNICATION OF INTENT
During the PI Planning event team’s need to communicate their plan to the rest
of the release train on two separate occasions, Draft Plan Review at the end of
day 1 and Final Plan Review in the middle of day 2.

These plans need to be communicated quickly but accurately without digressing

into team level technical detail. The assembled audience wants to know what the
outwards value deliveries are from the team and the collaborations needed to
help with value delivery.

Just reading the team’s objectives should provide this focus; if a team has to
extemporize when reading their objectives then it’s a sign that the objectives
aren’t clearly describing the team’s intent.
Page 27

SECTION 4: PI OBJECTIVES BEYOND

PI PLANNING: REAFFIRMING AND
MONITORING YOUR COMMITMENTS
Previously we have focused on the evolution of good PI Objectives; in this final
section we look at how they are utilised during execution of the PI.

We will follow the sequence of activities undertaken by a team during the PI

starting with role the PI Objectives play in Iteration Planning and concluding
with how they help to close the PI as part of the program level Inspect and
Adapt.

TEAM ALIGNMENT / ITERATION

PLANNING
During the PI the teams work in series of time-boxed iterations. Regardless of
whether the team choose to base their team process on Scrum or Kanban they
should summarise their objective for the iteration as a set of committed Iteration
Goals; these are a more generalized version of what Scrum defines as a Sprint
Goal. The link aside is to the Sprint Goal card from the Essence based Scrum
Essentials Practice developed in conjunction with Scrum Inc. Visit our Coaching
Card Download Hub to grab the cards and learn more.

The PI Objectives provide context, and an obvious source, for the team’s Iteration
Goals. Typically, a team will take one or more of their PI Objectives to directly act
as their Iteration Goals. This gives the team a focus and helps steer them towards
selecting the set of stories that will deliver the desired value. Focusing on just one
or two of the PI Objectives at a time also helps keep Work-In-Process limits low.
Page 28

During the Iteration planning process, the scores assigned to the PI Objectives
can be used by the team to help make sensible decisions. It is important to
remember that the score assigned to a PI Objective is a relative summary of its
business value. This is one of the inputs used by the team when deciding what to
work on. To plan the iteration the team needs to consider many other factors
such as effort, risk, architectural impact, availability of people and resources etc.

The team’s purpose is to optimize the value delivered and it may make sense to
deliver a number of smaller less-valuable items than to attempt to address a
single very large, time-consuming item of equivalent or higher value.
In some cases, a PI Objective will take more than a single iteration to achieve; in
this case the Iteration Goal should show some measurable progress towards the
objective.

The advice in the earlier blogs on writing good PI Objectives also applies to
writing good Iterations Goals. If the PI Objective is being used directly as one of
the Iteration Goals, then it is already well-formed and can be used as is.

CONTINUOUS MANAGEMENT
INFORMATION / ITERATION REVIEW
The PI Objectives provide an excellent way of communicating what’s going on to
upper management:

they’re written in human readable language

they’ve seen them before – they are what they accepted as part of the Final
Plan Review

they focus on value

they represent the tangible commitments made by the team(s)

Page 31

The best things about them are that they 1) allow us to see what has been
achieved 2) enable us to keep the business owners engaged throughout the PI
and 3) they allow us to regularly reaffirm the team’s commitment.

Working with a number of our customers we have developed a very simple

“commitment tracker” for use by the individual teams. This is usually
implemented as part of each team’s public wiki pages.

It involves the publication of each team’s PI objectives and their tracking across
the Iteration in the PI. At the end of PI Planning it would look like the following;

Here the objectives are listed in the first column – usually these would be the full
objective with clear measurable results but here just a tag-line is shown to keep
the illustration simple. The second column shows whether the objectives were
un-committed objectives or fully committed ‘core’ objectives.

The final two columns show 1) the planned Business Value and 2) the actual
Business Value achieved. We’ll discuss the scoring of the objectives in more
detail in the next section. As Figure 1 shows the table at the end of PI planning
there are no actual scores to be shown.

The middle six columns are used to show the team’s original and on-going
commitments using a simple colour code.
Page 32

As seen in the previous illustration, it is very easy to see which of the objectives
the team has fully committed to. The graphic below shows the same team’s
tracker at the end of Iteration 2.

Here an additional adornment has been used to show when an objective has
been achieved and the team has therefore completed its work on it. In this case
we have used a thumbs-up, but a simple tick would work just as well.

Now we can clearly see how the team is progressing and how its plans are
changing based on what has been learnt from their first two iterations. The team
has completed two of its objectives and has realized that the first of the stretch
objectives is not going to be completed during this PI and that the fourth
objective is now at risk.
Page 33

The use of the ‘commitment tracker’ clearly communicates to the Business

Owners and everyone else involved how the team is progressing providing a
great basis for value focused conversations and decision making.

Teams’ indicate the state of their own objectives, which can in turn be
aggregated to the Program Objectives. Typically, all teams need to have
completed their contributing objectives for an aggregate objective to be marked
as complete. If a team changes its level of commitment on an objective that
contributes to an aggregate objective then this can be reflected in the
commitment shown on the shared objective.

The commitment tracker is completed as part of a team’s Iteration Review. This

reaffirms the team members commitment, makes sure they don’t take their eye
off the ball and forget the things they committed to in PI planning, and helps
prepare them for the next Iteration or PI planning meeting.

This information is typically broadcast within the program, upwards to business

owners, and across to other teams and trains. If anyone wants more regular
updates, or a finer granularity of information than this broadcast provides, then
they need to start investing time and effort to attend the team level events and
to learn how to utilise the team level tooling.
Page 34

With the application of a little more discipline around the planning of the
objectives, it’s very easy to spot infractions of our Agile Principles; namely SAFe®
Principle #6: Visualise and Limit Work-In-Process. If the team plans to start
working on all the objectives in the first Iteration then something is wrong.

We have found that using the PI Objectives in this way, as an integral part of the
iterative process, helps keep everyone focused, increases business transparency,
enables increased business engagement, and ultimately helps fight the entropy
that leads to teams becoming an un-thinking Feature or Story factories rather
than value delivery teams.
Page 35

HANDLING CHANGE / BACKLOG

REFINEMENT
Change is inevitable and Agile Manifesto Principle #2 is “Welcome changing
requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.”

As change happens and new work comes in; other work will need to be removed
to make space for it. If the new work is large and not related to the existing
objectives, then new Objectives will need to be put in place and existing
objectives down-graded from Committed to Planned or Planned to Not
Happening. We are dealing with a fixed capacity. We cannot add new objectives
to the train without removing some of the existing ones.

Obviously, any new objectives will need to be scored and shown to have a greater
urgency and value to effort ratio than the ones they are replacing. Remember
you cannot prioritize based on value alone so, just as it is for Features, it is not
always the most valuable objectives that make the cut.

Any new objectives will be treated as stretch of objectives when being added to
the table, even if they are replacing one of the team’s original core objectives. We
need to retain the initial baseline set of objectives to support the predictability
measure at the end of the PI.

Not all new Features and Stories requested will require new objectives. As seen
earlier in the series we will have objectives related to maintenance and support,
many of which will not have specific sets of Features or Stories identified up front
for them. The Product Management Team will be constantly refining the
Program and Team backlogs based on the current PI Objectives and the team’s
focus.
Page 36

The first question to ask when receiving any new Features or Story requests is
“What does this mean for the current PI? How does it affect our current PI
Objectives?”. Once again having the information on the state of the PI Objectives,
in the form of the ‘commitment tracker’, is incredibly helpful when managing the
backlogs.

CLOSING THE LOOP / SCORING THE

OBJECTIVES
The Objectives and the scores attached to them during PI Planning are used to
close the loop on commitment at the end of the Program Increment. This serves
two purposes; it acts as a forcing function to generate more conversations
between the Business Owners and the Agile Teams and it generates a
predictability metric. We’ll cover the Predictability Measure in the next section.

It’s at this point that SAFe®’s phrase “Business Value” can be potentially
troublesome. What we don’t want is the Business Owners to come along and say,
“thanks for delivering all that we requested; now that we’ve seen it we realise
that it’s not valuable; therefore we’re going to score this as 0.” If the team
delivered then the team should get the full score. What we are looking at here is
whether the teams achieved what they set out to do NOT how good the Business
Owners are at ‘guestimating’ the value of the individual objectives. We also want
to avoid the unpleasant situation where teams try to up the value of the things
they’ve done to cover up for the things that they haven’t done.
Page 37

It is also important not to revise / re-work the originally assigned value as we

want to use the numbers to drive a predictability measure – a measure that
won’t work if we fiddle with the inputs.

In the example above (Figures 1 to 4) you may be wondering “Why are the
objectives not being scored as and when they are completed?” Well, this is a sad
a reflection on the lack of involvement from most Business Owners. In an ideal
world the Business Owners would be actively involved throughout the PI and
could score any objectives completed in an iteration as part of that iteration’s
System Demonstration.

If the Business Owners are not engaged enough to ‘accept’ the objectives in this
way, then have Product Management accept the objectives as they are achieved,
and the Business Owners score them after the PI System Demo as part of the
Inspect and Adapt.

Having seen the appropriate System Demonstration the Business Owners

discuss with the team how much of each Objective was delivered; this should be
a two-way discussion. Sometimes teams have as much of an opinion on how
much they achieved as the Business Owners; they were doing the work after all
therefore they know how much they’ve done.

This discussion also facilitates knowledge transfer; the engineering staff learn
what and why certain things were important to the Business Owners and the
Business Owners start to learn what challenges the teams are facing so that they
can prioritise future features and enablers accordingly. And everyone learns how
to write better objectives next time – if there is a lot of debate over whether or
not an objective was achieved then it probably wasn’t very well formed in the first
place.
Page 38

Sometimes the PI Objectives are black or white, there or not-there. In this case if
the objective was achieved then it gets the full score that was given to it in PI
planning, otherwise it gets 0. In other cases there is more of a sliding scale and
the team can be given some credit even if all the desired results were not
achieved.

Take for example an objective to speed something up by 50%. This would make a
good measurable objective but may be very difficult to achieve, with the team,
for example, only achieving an improvement of 30%. It is up to the Business
Owners to assess the value of this increase in speed. It is less than they hoped for
but still of significant value. If the original score was 10 the Business Owners may
well give the team 8 out of 10 in this case. It will be up to them to judge the value
delivered and score the objective appropriately.

We should also be careful not to overthink or overly quantify what we mean by

value. As discussed in the previous section this is a score that reflects the relative
importance of a team’s objectives to the Business Owners at the time the plans
were made. It is not an absolute value and is not comparable between teams.

The last thing we want is the Business Owners to come along and say, “thanks for
delivering all that we requested; now that we’ve seen it we realise that it’s not
valuable; therefore we’re going to score this as 0.”, if the team delivered then the
team should get the full score.

Any new objectives should be scored in exactly the same way as the original
objectives. This is why it is so important that the Business Owners are involved in
the change process and agree the value of any new objectives before the team
commits to them. Any objectives that were abandoned because their work was
moved out to make room for new objectives will score 0.

What happens if the team come up with, and deliver on, some of their own
objectives during the PI and don’t involve the Business Owners? Well in this case
they provide us with a fantastic learning opportunity. They should definitely be
presented to the Business Owners for scoring as part of closing out the PI. Our
goal is full transparency and it is always interesting to see how the involved
parties react.
Page 39

CLOSING THE LOOP / THE SAFE®

PREDICTABILITY MEASURE
The number one metric referenced in all the SAFe® training material is the
Program Predictability Measure. This is the only measure that gets specifically
called out and illustrated in the Leading SAFe and Implementing SAFe courses.
The reason that it is such an important measure is that predictability is an
essential precursor to any experiment-based approach to improvement. If the
system is unpredictable how will you be able to interpret the impact of any
changes that you make to the team’s way-of-working.

The predictability score is calculated by the sum of the actual value achieved as a
percentage of the planned / committed value - the sum of the value assigned to
the core objectives by the Business Owners during the planning event. The
stretch objectives aren’t included in the calculation of the planned / committed
value, but their actual scores are included when calculating the teams actual
score.

This means that teams can score greater than 100% if they manage to deliver
their stretch objectives. Now this is not a problem but it is also not the objective.

Any team that is consistently delivering over 100% is probably declaring too many
of their objectives as stretch objectives; are they trying to make themselves look
good by gaming the system rather than highlighting that there is true risk
inherent in those objectives? As the predictability score uses the values assigned
for each objective (and doesn’t just count them and treat them all equally) it is
also naturally weighted towards the PI Objectives that the Business Owners felt
were most important – the ones they awarded the highest scores.

Any new objectives that were added once the PI was started are treated in the
same way as the stretch objectives when calculating the scores. The added
objectives don’t contribute to the planned score because they weren’t part of the
committed set, but they do contribute to the actuals at the end. The calculated
predictability score shows that the team is still predictably delivering even to an
evolving plan.
Page 40

This image from the Scaled Agile Framework succinctly sums up how the
predictability measure is presented and how the overall program predictability is
derived from that of the individual agile teams.

The desired operating band for the predictability measure is deliberately a range,
typically 80-100%. This is shown as the green band on the graph in shown above.

The fact that it is a range is important; it gives the teams some room for
manoeuvre. If they were tasked with achieving an absolute value then there
would be a tendency to manipulate the numbers to exactly achieve that value
whereas when trying to land within a range the truth can shine through. The
range also provides space to absorb the variations inherent in our delivery
processes.
Page 41

The results provide lots of food for thought; individual teams might be out of
range, get beyond the numbers and find out what problems have afflicted the
teams. It might not be a bad team; it might be that the team sacrificed
themselves (for example they took all the incoming defects) to allow other teams
to maintain their predictability. The key metric, the one to broadcast outside the
Agile Release Train, is the aggregate metric for the train as a whole.

If that Predictability score is in the 80-100% region then the Business Owners can
start to trust that 4 out of 5 things committed to at PI Planning will come out the
end of the Program Increment; perfection is impossible because teams are
dealing with problems that have never been solved before and some of those
problems might not have economically viable solutions.
Page 42

FINAL WORDS
Over the course of this blog series we’ve explored all aspects of the generation
and use of PI Objectives in SAFe®. We have seen why they are such a vitally
important part of the framework, how they are generated, and how they are
utilised within execution and closing the loop on commitment to a plan.

We have seen how they are an integral part of every one of the management
activities in the framework from PI and Iteration Planning to Backlog Refinement
and Inspect and Adapt, When used properly they prevent us from degenerating
into a feature factory, enable the empowerment of the teams, bridge the gap to
the sponsors and other business owners and, possibly most importantly, provide
the predictability that is needed to support our on-going, relentless
improvement.

We’ve also tried to share our practical experience gained across through many
years and many PIs in many different organisations, and to tie everything back to
the underlying principles that are the guiding force within agile and SAFe®.

Thank you for taking the time to download our 'Writing Good PI Objectives' PDF.
You can read the individual articles on the IJI website here, and access our Scaled
Agile® related resources here.

The IJI website is home to a great deal of useful resources, from Agile 'Serious
Game Cards' to practical video workshops to improve your SAFe® practices,
among others.
Page 43

Thank you for taking the time to download our 'Writing Good PI Objectives' PDF.
You can read the individual articles on the IJI website here, and access our Scaled
Agile® related resources here.

The IJI website is home to a great deal of useful resources, from Agile 'Serious
Game Cards' to practical video workshops to improve your SAFe® practices,
among others.

Inspired? Looking for more content and resources

to aid in your PI objectives journey?

How Many Features do you need for PI Planning?

WSJF & Feature Slicing

All about the PI Planning Management Review &

Problem Solving

Secrets of Dispersed PI Planning

Estimating in Story Points