This document provides guidance on creating valuable PI Objectives in SAFe organizations. It defines PI Objectives as summaries of business and technical goals for an Agile Release Train (ART) in an upcoming Program Increment (PI). The document outlines benefits like focus, alignment, and learning. It discusses potential struggles and offers templates to help teams craft clear, measurable objectives. Examples demonstrate how to make objectives specific and focus on user/business impact. Metrics and acceptance criteria are emphasized to evaluate if objectives were achieved. Finally, case studies show potential outcomes with and without proper use of PI Objectives.

1. Transforming organizations into software-driven responsive enterprises
Creating Valuable PI Objectives
“If you don't know where you are going, you'll end up someplace else.” ~ Yogi Berra
Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018 – v1.1.2
Always find the most recent version of this document: http://sjoerdly.com/PI_Objectives

2. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
A PI Objective is ‘just’ a
large Sprint Goal.
Both describe the WHY of
an effort.
PI OBJECTIVES IN A NUTSHELL
2

3. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Goals/Objectives of this document
• Help teams apply the practice of PI Objectives* in
a valuable way;
• Create clarity on the use of PI Objectives for
beginners and practitioners;
• Summarize the knowledge and context as
provided in the Scaled Agile Framework (SAFe);
• Provide starting examples/templates to limit the
cognitive load needed when crafting PI Objectives
during PI Planning;
• Prevent distress, disconnectedness, helplessness,
hopelessness and general lack of ownership
during PI planning by providing insight and
potential benefits of the practice;
• Provide a clear basis for the teams as a starting
point for learning.
This document is intended to help teams who want to
benefit from the practice of setting PI Objectives. PI
Objectives are a SAFe practice and are
interconnected with to other SAFe practices. This
document will presume you work in a SAFe context,
that is, are organized in an Agile Release Train and
organize PI Planning and Inspect & Adapt Events.
Teams should experiment and find their own groove
when it comes to creating valuable Objectives. Don’t
blindly follow every template here. Make it your own.
Make it Work. You can do it!
* PI is short for Program Increment. Throughout this
document the shorthand will be used in various
combinations, like PI Objectives, and assumed
known.
AIM OF THIS DOCUMENT
3

4. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
In SAFe PI (Program Increment) Planning, we create
PI Objectives to give us direction. In the PI Objective
the WHAT and the WHY are made clear. The
Objective explains why it is a good idea to carry out
the sprint an implement the stories. This results in a
clear way of communicating what we are aiming to
achieve. (The how is made clear in the Features &
Stories).
Definition of a PI Objective
• a summary of the business and technical goals
that an Agile Team or train intends to achieve in
the upcoming Program Increment (PI).
Intended benefits
Focus
• Aligns the train with a shared mission;
• Creates the near-term vision, which teams can
rally around and develop during the PI;
Alignment & shared understanding
• Provide a common language for communicating
with business and technology stakeholders;
• Communicates and highlights each team’s
contribution to business value;
• Exposes dependencies that require coordination
Learning
• Enables the ART to assess its performance and
the business value achieved via
the Program Predictability Measure;
• Validates understanding of intent (quick feedback
on understanding).
WHAT ARE PI OBJECTIVES?
4

5. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
In practice, teams often struggle with defining clear
objectives that are well understood by both the
Business Owners, Stakeholders and Development
Team(s).
As a result, often many smaller ‘objectives’ are
defined, that are hard to discern from Features or
even User Stories. In this form, PI Objectives don’t
add value since they are often technical/functional.
This impedes communicating with Stakeholders about
goals and business value of the PI.
Potential negative side-effects
• Stakeholders don’t get what we are working on.
They don’t understand & value the teams’ efforts in
worst case leading to mistrust;
• Business Owners, Product Owners & Program
Management have trouble aligning the Business
and other development efforts on important goals
in time;
• Teams feel like creating Objectives is a chore and
it doesn’t add value to them;
• Business Owners have trouble assigning Business
Value to the created Objectives.
THE STRUGGLE WITH PI OBJECTIVES
5

6. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Feature PI Objective
Service that fulfills a Stakeholder need Business/Technical Goals & Milestones
Short phrase (name & context) Simple business terms
Benefit Hypothesis + Acceptance Criteria S.M.A.R.T.
WSJF (incl. size: PI > Feature > Sprint) Business Value (1-10)
Development Output Business Outcome
Facilitates conversation on functionality &
product changes
Aligns teams on a near term Vision
Typically adresses multiple user roles Validates understanding of intent
Typically for 1 team (sometimes multiple) 2 levels: Team & Program PI Objectives
Ordered, forecast in time Valued & measured (yes/no, quantitative, or
provide a range)
Flexible plan (forecast) Committed (except Stretch Obejctives)
‘Large User Story’ ‘Large Sprint Goal’
FEATURES VS OBJECTIVES
6

7. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
In PI Planning, teams summarize the information
of their plan into simple business terms that can be
understood by everyone. This is a high level
overview of the steps taken to create PI Objectives
during the 2-day event.
1. Each team pulls from the Features presented,
in addition to team-specific work (Features &
Stories from Team Backlog);
2. Teams collaborate to plan the realization of
Features in their iterations (Sprints), with help
from whomever is needed. Teams gain clarity
on the Who, Why, What & How;
3. From this clarity, teams start identifying draft
PI Objectives from coherent sets of Features,
Enablers and Stories;
4. At the end of day 1 each team has a draft
plan (Features, Enablers and Stories planned
in iterations) & draft Team PI Objectives;
5. During day 2 teams refine their plans &
objectives, including dependencies and
shared objectives. Teams are expected to
collapse similar/shared objectives to the same
phrase/sentence. Stretch Objectives are
identified. Business Value is assigned;
6. At the end of day 2 – after ROAMing the
identified risks – the Train commits to PI
Objectives (excluding Stretch) using the
confidence vote;
7. Product Management (facilitated by RTE) is
responsible for rolling up Team PI Objectives
into Program PI Objectives in a format
suitable for management communication.
GETTING TO PI OBJECTIVES IN PI PLANNING
7

8. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Since PI Objectives can be seen as large Sprint
Goals, many of the advice on crafting a great Sprint
Goal applies to PI Objectives as well. The only
difference here is that there should be only one Sprint
Goal, while multiple Objectives per team are allowed,
since they are describing a longer timeframe. But
having just one is perfectly fine too. Objectives can be
shared across teams too. As long as they help create
Focus and shared understanding.
1-5 Objectives per Team
Every team should have at least one PI Objective and
as many as are needed to cover the majority of the
work forecasted in the Features they plan to deliver
(or contribute to). Less is more: having more than five
leads to lack of Focus and muddles shared
understanding of the whole.
Questions to start with
• Why do we carry out the PI? Why is it worthwhile
to run a PI? What should be achieved?
• How do we reach its Objective? Which artefact,
validation technique, and test group are used?
• How do we know the Objective has been
met? For instance at least three of the five users
carry out the usability test successfully in less than
a minute.
CREATING PI OBJECTIVES:
QUESTIONS TO START WITH
8

9. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Since Objectives are all about focus, here are some
ways to help find focus from different angles. While
there are many ways to create focus, these three
seem to be a good place to start from.
Three ways to focus
• Make it business or user focused when
possible. What will a user be able to do when we
implement this feature? What will a business area
be able to achieve when we implement an
enhancement?
• Make it focused on testing business
assumptions and getting feedback. Many times
we do not know what is actually needed or what
will best fulfill the business or customer
need. Teams need early feedback to test
assumptions regarding value to Stakeholders.
• Make it focused on reducing risk. Proving out a
technology or design is an important part of
reducing risk. If we learn that a technology is not
going to meet our needs for performance, security,
or scalability, we can change direction. The earlier
we change direction, the cheaper the cost of the
change.
CREATING PI OBJECTIVES:
THREE WAYS TO FOCUS
9

10. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Any goal or Objective is only as useful as the learning
they support. To make sure these Objectives are not
‘set & forget’, we can apply SMART rules to ensure
that the Objectives serve their purpose of Focus,
shared understanding and learning.
Apply SMART rules
• Specific & Measurable
• Allowing to determine success;
• Elicit Stakeholder feedback &
collaboration;
• Binary evaluation is ok, success
percentages are better (Objective met
with 80% impact of forecast).
• Attainable
• Impact on this Objective can be made in
the PI;
• It is realized by the selected Features;
• Stretch Objectives are potentially
attainable (‘good weather forecast’).
• Relevant
• PI Objectives align with the Product &
Business vision;
• PI Objectives align with Business
Strategy & Roadmaps.
• Time-bound
• Should be evaluable & attainable within
the PI timeframe.
CREATING PI OBJECTIVES:
MAKE THEM SMART
10

11. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Unclear Objective Clearer Objective
Enhance shopping cart functionality. Streamline purchasing process to enable an
increase in conversion rates.
Improve performance. Increase page load time by X%, so customers
experience less frustration.
On-board new market segment. Enable new market segment to purchase
Service Y.
Reduce service workload. Reduce workload of service representatives
by Z%.
Remove legacy data structures. Improve maintainability & stability by
reducing nr of incidents by N, so teams have
more time for innovation.
EXAMPLE PI OBJECTIVES
11
The unclear Objectives are too broad and general. Try to make Objectives clear and focused. Also, the Objectives on the left
are more like descriptions of how we want to change, instead of describing the expected/desired impact.

12. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
PI OBJECTIVE TEMPLATE: STORY SPINE
When creating Story Spines, Start at the edges and work your
way in. Post its may be a handy tool to enable creative shuffling
and adjusting. This one is best suited for user-facing Features,
but can also be used for Enablers. Experiment!
1. Write down the opening and closing of the Spine. This
helps focusing on who benefits and what this benefit is.
The USER will typically be the user, customer or
stakeholder who benefits from the working Features and
whose problem we aim to solve;
2. Inject ‘Until <PI> by <team x(&y&z)>;
3. Fill the remaining steps of the template. Focus on one
problem, aim for 1-3 features;
4. Review and iterate until the goal makes sense.
Collaborate with Business Owners & other Stakeholders
to clarify;
5. Rinse & Repeat until all Features & Enablers are covered;
6. Use the resulting paragraph on its own, or inject it in the
table of the next slide.
Story Spine template for a PI Objective
Once upon a time there was a <USER>
Every day the <USER> faces a <PROBLEM>
Until this Program Increment
Because of <SOLUTION / FEATURE A>
And because of <SOLUTION / FEATURE B>
And because of <SOLUTION / FEATURE C>
Finally, the <USER> solves their <PROBLEM>
And ever since then the <USER> gains
<BENEFIT>
12

13. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
PI OBJECTIVE TEMPLATE: SIMPLE STRUCTURE
When creating a simple Objective structure, start with
the knowns like the Product and the PI name. Use
facilitation techniques to prevent groupthink and loudest
voice decides.
1. Brainstorm on possible goals based on the selected
features for the Objective. For instance all team
members create potential goals individually;
2. Pool & select the best candidate Objectives and
refine them according to the tips in this document;
3. For each Objective, ‘Method’ should contain
reference to features that help meet this objective,
and even better, specific acceptance criteria that
contribute’to the Objective. This is how we make it
specific;
4. For each Objective, ‘Metrics’ should list ways we
intend to make the result of the Objective
measurable.
PRODUCT
/ SERVICE
Product Name
PROGRAM
INCREMENT
PI number or name
Business
Value
Expected/realised
PI OBJECTIVE
Why is it worthwhile to run the PI? What should be achieved? For
instance, address a risk, test an assumption, or deliver a feature. Is
this a Stretch Objective or a regular one? Optionally use the Story
Spine format here (see next slide).
METHOD
How is the Objective met? Which 1) artefact, 2) validation
technique and 3) test group are used? For instance, 1) paper
prototype, spike, shippable increment; 2) product demo, usability
test, A/B test; 3) users, customers and/or internal stakeholders.
METRICS
How do you determine if the Objective has been met? For
instance, at least three of the five users carry out the usability test
succesfully in less than a minute.
13

14. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
PI OBJECTIVE TEMPLATE:
SIMPLE STRUCTURE (EMPTY)
PRODUCT / SERVICE
Product Name
PROGRAM INCREMENT
PI number or name
Business Value
Expected/realised
PI OBJECTIVE
Why is it worthwhile to run the PI? What should be achieved? Who Benefits (stakeholders)?
METHOD
How is the Objective met? Which 1) artefact, 2) validation technique and 3) test group are used?
METRICS
How do you determine if the Objective has been met?
14

15. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
PI OBJECTIVE TEMPLATE:
ALTERNATE SIMPLE STRUCTURE (EMPTY)
PRODUCT / SERVICE
Product Name
PROGRAM INCREMENT
PI number or name
Business Value
Expected/realised
PI OBJECTIVE
What do we want to achieve? Title/one sentence description, including the goal of this Objective.
STAKEHOLDERS
Who benefits from the changes we are making? Who is impacted by realizing this Objective?
ADDED VALUE
Why is this valuable to the customer, user and/or company? How will we know this value is realized?
15

16. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Assigning Business Value Evaluating Business Value
During PI Planning During I&A (Inspect & Adapt)
Business Owners Business Owners
1-10 1-10
Collaboration with teams Based on Stakeholder feedback & metrics
Forecasted value of Objectives Actual value of delivered functionality
Forecast total (excluding Stretch) Realized Total (including Stretch)
Entire Train commits to non-Stretch
Objectives
Updated Program Predictability Measure
ASSIGNING & EVALUATING BUSINESS VALUE
16

17. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
No PI Objectives – Possible!
A national mortgage division worked without PI
Objectives. They had enough transparency, focus and
collaboration from Feature planning only.
Collaboration with Business Owners and other
Stakeholders went well, for example having the right
discussions and decisions during PI Planning
(management review).
Half PI Objectives – detrimental effect
An international publisher’s division used PI
Objectives temporarily & half-baked. No Business
Value was assigned, they were not made SMART and
evaluated properly. Not closing the feedback loop
created stress and lack of clarity and collaboration
between the teams and the Business Owners.
Proper PI Objectives – Painfully transparent
The insurance devision of a large Bank used PI
Objectives to sumarize what they hoped to achieve in
a Program Increment. In the second PI planning this
went quite smoothly. However, from this planning it
became clear that reaching the desired business
outcomes wold take much longer than they had
hoped, and was not realistically expected to deliver a
good return on investment. Within the next half year
the program was stopped and the development
capacity allocated to other efforts.
REAL WORLD CASES
17

18. Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018
Scaled Agile Framework
• PI Planning
• PI Objectives & The Role of PI Objectives
• Features & SAFe requirements model
• Milestones
• Program Predictability Measure
Sprint Goals (very similar to PI Objectives)
• Effective Sprint Goals (Pichler)
• Creating Good Sprint Goals (Scrum.org)
• Story Spines Retro technique (Tastycupcakes)
• Story Spines background (Pixar a.o.)
RESOURCES ON PI OBJECTIVES
18

19. www.prowareness.nl
Office Bangalore (IN)
Building 2A-West Tower,
Embassy Tech Village
Outer Ring Road, Deverabeesanahalli Village,
Bangalore – 560087, Karnataka, India
+91 80 49 08 78 00
www.prowareness.com
info@prowareness.com
Office Düsseldorf (DE)
Stadttor Medienhafen 17. Etage
Stadttor 1, 40219 Düsseldorf
Germany
+49 211 3003 401
www.prowareness.de
www.scrum.de
info@prowareness.de
Office Silicon Valley (US)
530 Lytton Avenue
2nd Floor
Palo Alto, California
94301, United States
+1650 617 3267
www.prowareness.com
info@prowareness.com
Headquarters Delft (NL)
Brassersplein 1
2612 CT, Delft
The Netherlands
+31 15 241 18 00
www.prowareness.nl
www.scrum.nl
info@prowareness.nl
Creating Valuable PI Objectives
“If you don't know where you are going, you'll end up someplace else.” ~ Yogi Berra
Sjoerd Kranendonk – s.kranendonk@prowareness.nl – 2018