Creating Valuable PI Objectives v1.2.0

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.2.0
Always find the most recent version of this document: http://sjoerdly.com/PI_Objectives

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

Goals/Objectivesof this document
• Help teams apply the practiceof PI Objectives*in a
valuable way;
• Create clarityon the use of PI Objectivesfor beginners
and practitioners;
• Summarizethe knowledge and contextas provided in
the Scaled Agile Framework (SAFe);
• Provide startingexamples/templatesto limit the
cognitiveload needed when craftingPI Objectives
during PI Planning;
• Prevent distress,disconnectedness,helplessness,
hopelessness and general lack of ownership during PI
planningby providing insight and potentialbenefitsof
the practice;
• Provide a clear basis for the teams as a startingpoint
for learning.
This documentis intended to help teams who want to
benefit from the practiceof settingPI Objectives.PI
Objectivesare a SAFe practiceand are interconnected
with to other SAFe practices.This document will presume
you work in a SAFe context, that is, are organizedin an
Agile Release Train and organizePI Planningand Inspect
& Adapt Events.Teams should experimentand findtheir
own groove when it comes to creatingvaluable
Objectives.Don’t blindly follow every templatehere.
Make it your own. Make it Work. You can do it!
* PI is short for Program Increment.Throughoutthis
documentthe shorthand will be used in various
combinations, like PI Objectives,and assumed known.
AIM OF THIS DOCUMENT
3

In SAFe PI (Program Increment)Planning,we create PI
Objectivesto give us direction.In the PI Objectivethe
WHAT and the WHY are made clear. The Objective
explains why it is a good idea to carry out the Program
Incrementand implementthe features. This results in a
clear way of communicatingwhat we are aimingto
achieve. (The how is made clear in the Features &
Stories).
Definitionof a PI Objective
• a summary of the business and technicalgoals that an
Agile Team or Agile Release Train intendsto achieve in
the upcomingProgram Increment(PI).
Intendedbenefits
Focus
• Aligns the Agile Release Train with a shared mission;
• Creates the near-termvision,which teams can rally
around and develop duringthe PI;
Alignment& shared understanding
• Provide a commonlanguage for communicatingwith
business and technologystakeholders;
• Communicatesand highlights each team’s
contributionto business value;
• Exposes dependenciesthat require coordination
Learning
• Enables the ART to assess its performanceand the
business value achieved via
the Program PredictabilityMeasure;
• Validatesunderstandingof intent(quick feedbackon
understanding).
WHAT ARE PI OBJECTIVES?
4

In practice,teams often struggle with definingclear
objectivesthat are well understoodby both the Business
Owners,Stakeholders and DevelopmentTeam(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 Objectivesdon’t add value since
they are often technical/functional.This impedes
communicatingwith Stakeholders about goals and
business value of the PI.
Potentialnegativeside-effects
• Stakeholders don’t get what we are working on. They
don’t understand& value the teams’ effortsin worst
case leading to mistrust;
• Business Owners,Product Owners & Program
Managementhave trouble aligningthe Business and
other development effortson importantgoals in time;
• Teams feel like creating Objectivesis a chore and it
doesn’t add value to them;
• Business Ownershave trouble assigning Business
Value to the createdObjectives.
THE STRUGGLE WITH PI OBJECTIVES
5

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

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

SincePI Objectivescan be seen as large Sprint Goals,
many of the advice on craftinga great SprintGoal applies
to PI Objectivesas well. The only differencehere is that
there should be only one Sprint Goal, while multiple
Objectivesper team are allowed, sincethey are
describing a longer timeframe.But having just one is
perfectlyfine too. Objectivescan be shared across teams
too. As long as they help createFocus and shared
understanding.
1-5 Objectivesper Team
Every team should have at least one PI Objectiveand as
many as are needed to cover the majorityof the work
forecastedin the Features they plan to deliver (or
contributeto). Less is more: having more than five leads
to lack of Focus and muddles shared understandingof
the whole.
Questionsto 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,
validationtechnique,and test group are used?
• How do we know the Objective has been met? For
instanceat least three of the five users carry out the
usabilitytest successfully in less than a minute.
CREATING PI OBJECTIVES:
QUESTIONS TO START WITH
8

SinceObjectivesare all about focus, here are some ways
to help findfocus from differentangles. 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
implementthis feature? What will a business area be
able to achieve when we implementan
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 customerneed. Teams need early
feedbackto test assumptionsregardingvalue to
Stakeholders.
• Make it focused on reducing risk. Proving out a
technology or design is an importantpart of reducing
risk. If we learn that a technologyis not goingto meet
our needs for performance,security, or scalability,we
can change direction. The earlier we change
direction,the cheaper the cost of the change.
THREE WAYS TO FOCUS
9

Any goal or Objectiveis only as useful as the learningthey
support. To make sure these Objectivesare not ‘set &
forget’,we can apply SMART rules to ensure that the
Objectivesserve their purpose of Focus, shared
understandingand learning.
Apply SMART rules
• Specific & Measurable
• Allowing to determinesuccess;
• ElicitStakeholder feedback & collaboration;
• Binary evaluationis ok, success
percentagesare better (Objectivemet with
80% impactof forecast).
• Attainable
• Impacton this Objectivecan be made in the
PI;
• It is realized by the selected Features;
• StretchObjectivesare potentiallyattainable
(‘good weather forecast’).
• Relevant
• PI Objectivesalign with the Product &
Business vision;
• PI Objectivesalign with Business Strategy&
Roadmaps.
• Time-bound
• Should be evaluable & attainablewithinthe
PI timeframe.
MAKE THEM SMART
10

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.

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

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

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

SIMPLE STRUCTURE WITH SENTENCE STRUCTURE (EMPTY)
PRODUCT / SERVICE
Product Name
PROGRAM INCREMENT
PI number or name
Business Value
Expected/realised
PI OBJECTIVE - BUSINESS OUTCOME – WHY, for WHO & WHAT
Why is it worthwhile to run the PI? What should be achieved? Who Benefits (stakeholders)?
Our goal is [GOAL in 1 SENTENCE]. Currently we experience negative business result [DESCRIBE IMPACT] because of situation [MAKE AS
IS EXPLICIT] with symptoms [X,Y,Z] for stakeholders [A,B,C]. The improvement we seek addresses [X,Y,Z] for stakeholders [A,B,C] in the
following way: [TO BE - 1,2,3]. We expect an improvement of [IMPROVEMENT] for our business as a result.
METHOD – OUTPUT - HOW
How is the Objective met? Which 1) artefact, 2) validation technique and 3) test group are used?
We aim to achieve our goal by implementing the following changes [CHANGES in product or service]. We expect this to lead to an
[IMPROVEMENT] because [SHORT EXPLANATION OF SOLUTION CHOICE].
METRICS – RESULT - VALIDATION
How do you determine if the Objective has been met?
The Objective is met when the following criteria are satisfied:
1. Validation
2. Acceptance Criteria
3. Metric improvement (by x percent or y points)
15

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?
16

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
17

No PI Objectives– Possible!
A nationalmortgagedivision worked without PI
Objectives.They had enough transparency,focus and
collaborationfrom Feature planningonly. Collaboration
with Business Owners and other Stakeholders went well,
for example having the right discussionsand decisions
during PI Planning(managementreview).
Half PI Objectives– Detrimentaleffect
An internationalpublisher’s divisionused PI Objectives
temporarily& half-baked. No Business Value was
assigned,they were not made SMART and not evaluated
properly. Not closing the feedback loop createdstress
and lack of clarityand collaborationbetween the teams
and the Business Owners.
Proper PI Objectives– Painfully transparent
The insurancedevision 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 planningit becameclear
that reaching the desired business outcomes wold take
much longer than they had hoped, and was not
realisticallyexpected to deliver a good return on
investment.Within the next half year the program was
stopped and the development capacityallocatedto other
efforts.
REAL WORLD CASES
18

Scaled Agile Framework
• PI Planning
• PI Objectives& The Role of PI Objectives
• Features & SAFe requirementsmodel
• Milestones
• Program PredictabilityMeasure
SprintGoals (very similarto PI Objectives)
• EffectiveSprintGoals (Pichler)
• CreatingGood SprintGoals (Scrum.org)
• Story Spines Retro technique(Tastycupcakes)
• Story Spines background(Pixar a.o.)
RESOURCES ON PI OBJECTIVES
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

Creating Valuable PI Objectives v1.2.0

Recomendados

Recomendados

Más contenido relacionado

Último

Último (20)

Destacado

Destacado (20)

Creating Valuable PI Objectives v1.2.0