REGISTER NOW

Framework About Blog Read More SAFe Training

“ Making and meeting small commitments builds trust.

—Nonaka and Takeuchi, The Knowledge-Creating Company

PI Objectives
PI Objectives summarize the business and technical goals that teams and trains intend to achieve in the upcoming PI and are either
committed or uncommitted.

During PI Planning, teams create PI objectives they intend to accomplish in the upcoming PI. These provide several benefits:

Provide a common language for communicating with business and technology stakeholders
Createsperformance
We use cookies to analyze website the near-term
and focus
visitor and
data,vision
deliver personalized content, and enhance your experience on the
Adjust Cookie Settings Accept
site. Cookie Policy. By clicking Accept you
Enables the consent to the use
ART to assess of all cookies. Otherwise
its performance click Adjust
and the business Cookie
value Settings.via the ART Predictability Measure
achieved

Communicates and highlights each team’s contribution to business value

Exposes dependencies that require coordination

Details
SAFe relies on a rolling wave of short-term commitments from Agile teams and trains to assist with business planning and outcomes,
resulting in improved alignment and trust between development and business stakeholders. These are communicated via PI objectives.

While development is uncertain by its very nature, the business depends on teams for some amount of reliable, predictable forecasting.
Too little, and the company can’t plan. Too much, and the organization has committed to longer-term plans, which are unreliable at best
and limit agility. Business and technology stakeholders need something in between, which is a primary purpose of PI objectives. In addition
to alignment, setting realistic objectives also helps avoid too much work-in-process (WIP) in the system. PI objectives are built largely
bottom-up as the teams identify them during PI planning.

Building the Team PI Objectives

During PI planning, the teams get presented with new Features and plan the Stories they need to deliver alongside stories representing
work from their local context. This work is described as a set of specific team PI objectives. Doing so requires estimating and planning,
knowledge of the team’s capacity, analysis of upcoming features, defining stories for the Team Backlog, and summarizing the information
into simple business terms everyone can understand.

As for the number of objectives a team should establish, there is no fixed rule, but 7-10 committed objectives (plus 2-3 uncommitted; see
below) seem to work best. Beyond this threshold, other teams and business partners find the details challenging to understand and
process. Plus, there are too many to review and process in a medium to large ART. Less, and the level of abstraction or aggregation is
probably too high to be measured objectively at the end of the PI.

Figure 1 illustrates an example of one team’s PI objectives.

Objectives for PI 1 BV AV

1. Show routing calculations

2. Navigate autonomously
3. Parallel park for a delivery
4. Return to the distribution
center after delivery
5. Include traffic data in route planning
6. Recall a delivery
7. Demonstrate real-time rerouting
to avoid delays (e.g., accident,
construction)

© Scaled Agile, Inc.

Figure 1. A team’s PI objectives

Differentiate between Features and PI Objectives

The team’s PI objectives often relate directly to intended features. Many are the same. However, the mapping is not always straightforward
since some features require the collaboration of multiple teams, as Figure 2 illustrates.

Objectives Objectives Objectives Objectives

Feature
A

Team 1 Team 2 Team 3 Team 4 …

ART Backlog

Feature
B

ASIC Board FW
FW Validation …

Feature Aspects
© Scaled Agile, Inc.

Figure 2. From features to objectives, some features will appear in more than one team’s PI objectives

Note that an individual team can deliver some features (such as Feature A); others (Feature B) require the collaboration of several teams. In
addition to features and inputs to features, other team objectives will also appear. These can include technical objectives (for example, the
proof of concept in Figure 1) that enable future features, enhancements to development infrastructure, milestones, and others. All the
planning process results are captured in the team’s objectives.

Features and acceptance criteria are excellent tools to help understand, capture, and collaborate around the work that needs to be done.
Still, it’s all too easy to get caught up in ‘finishing the features’ and missing the overall goals hiding inside. PI objectives help shift focus away
from developing features to achieving the desired business outcomes.

A better understanding of the intent offered by direct conversations with the Business Owners often results in the teams providing new
perspectives to System Architects and Product Management and quickly finding ways to apply their expertise to create better solutions.

(Note: The extended guidance article Role of PI Objectives further explains the differences between team PI objectives and features and
provides additional insights into their usage and value.)

Committed and Uncommitted Objectives

Committing to and delivering a series of short-term objectives helps to build trust. Trust allows all stakeholders to move forward confidently
and base decisions and plans on what is ‘very likely to be true very soon.’ But planning confidently in the face of the uncertainty inherent in
research and development is difficult. Things don’t always go as planned, and building some small amount of buffer into the system is
prudent. If the buffer is too big, the ART might accomplish less than would otherwise be the case. If the buffer is too small, many
commitments may not be feasible. As a result, planning and confidence erode. To address this, SAFe recommends teams use both
committed and uncommitted objectives during planning. Uncommitted objectives help improve the predictability of delivering business
value since they are not included in the team’s commitment or counted against teams in the ART predictability measure.

Uncommitted objectives are used to identify work that can be variable within the scope of a PI. The work is planned, but the outcome is
not certain. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective. This low confidence can
be due to many circumstances:

Dependencies with another team or supplier that cannot be guaranteed.

The team has little to no experience with functionality of this type. In this case, the teams may plan Spikes early in the PI to reduce
uncertainty.
There are a large number of critical objectives that the business depends on, and the team is already loaded close to full capacity.

In this case, a few (no more than 2-3) uncommitted objectives are prudent. However, teams do their best to deliver the uncommitted
objectives, and they are included in the capacity and plan for the PI. However, stakeholders plan accordingly since these objectives might
not be finished in the PI.

Uncommitted objectives provide several benefits:

Improved economics – Without uncommitted objectives, a team commits to a 100 percent scope in a fixed timebox. This forces
teams to trade off quality or build other buffers into the system. The other buffers can accumulate and convert ‘uncertain earliness
to certain lateness,’ resulting in less overall throughput.
Increased reliability – Uncommitted objectives represent variable scope, allowing confidence in delivering the main priorities. In turn,
delivering on the stated commitments is the most important factor in building trust between the teams and the stakeholders.

Adaptability to change – To reliably deliver on a cadence, uncommitted objectives provide the capacity margin needed to meet
commitments, yet alter priorities if necessary, when fact patterns change.

Write SMART PI Objectives

Team PI objectives summarize a team’s plan for the PI. They are critically important. Sometimes the descriptions may be very technical and
a little vague. As a countermeasure, teams make their objectives SMART:

Specific – States the intended outcome as concisely and explicitly as possible. (Hint: Try starting with an action verb.)

Measurable – It should be clear what a team needs to do to achieve the objective. The measures may be descriptive, yes/no,
quantitative, or provide a range.
Achievable – Achieving the objective should be within the team’s control and influence.

Realistic – Recognize factors that cannot be controlled. (Hint: Avoid making ‘happy path’ assumptions.)
Time-bound – The time period for achievement must be within the PI or sooner, so all objectives must be scoped appropriately.

Note: SMART PI objectives are similar to Key Results in the OKR format in that they are tangible and measurable. However, the OKR format
has proven less effective when applied to PI Objectives. See OKRs for more detail.

Communicating Business Value with PI Objectives

As objectives are finalized during PI planning, Business Owners collaboratively assign ‘business value’ to each team’s objectives face-to-face.
The value of this conversation with the team cannot be overstated, as it communicates the strategy and context behind these weighting
decisions. Business Owners use a scale from 1 (lowest) to 10 (highest) to rate each objective. One approach to assigning business value is
to ensure each team has one or more 10s for their highest priority objectives, which can help avoid unhealthy comparisons between
teams. An alternative approach is to ‘normalize’ business value across teams, meaning not all teams will have a 10 (or even 9s or 8s). This
can help teams focus on the highest value objectives across the ART and can swarm if needed to ensure the highest value is delivered in
the PI.

Business value is assigned, not calculated, and serves as an input to execution considerations. Many of the team’s objectives provide direct
and immediate value to the solution. Others, such as Enablers (for example, advances in infrastructure, development environments, and
quality initiatives), allow the creation of future business value faster. All of these factors must be weighed in the final balance.

Finalize Team PI Objectives

When objectives have been made ‘SMARTer,’ uncommitted objectives have been identified, and business value has been established, the
objectives in Figure 1 might evolve to look like those in Figure 3.

Figure 3. The team’s final PI objectives with business value assigned

Commit to PI Objectives
A vote of confidence is held near the end of PI planning, where the teams commit to the PI objectives. (Uncommitted objectives are not
included in this commitment.) However, it must be a reasonable ask for the people who do the work. Therefore, the SAFe commitment has
two parts:

Teams agree to do everything reasonably in their power to meet the committed objectives

During the PI, if it’s discovered that some objectives are not achievable, then the teams agree to immediately escalate so that
stakeholders are informed and corrective action can be taken

In this way, all stakeholders know that either the ART results will be achieved as planned or they will be provided sufficient notice to mitigate
and take corrective action, minimizing business disruption. That’s about as good as it gets because this is, after all, research and
development.

Creating ART and Solution Train PI Objectives

The output of the PI planning process will be a collection of approved team PI objectives. Teams vote on the confidence level for the
objectives as a set, and if confidence is high enough, the aggregate set of objectives becomes the committed ART plan. The Release Train
Engineer summarizes the team objectives into the ART PI objectives in a format suitable for management communication.

The summarized objectives should be SMART, like the team PI objectives, and have uncommitted objectives. Also, like the team PI
objectives, the ART PI objectives might describe business features the ART is working on, enablers, or other business or technical goals.

If the ART is part of a Solution Train, the objectives are further rolled up by the Solution Train Engineer, and the Solution Train PI objectives
are synthesized and summarized. This is the top level of PI objectives in SAFe, and they communicate to stakeholders what the Solution
Train will deliver in the upcoming PI. Figure 4 below illustrates this summary from team to ART and from ART to Solution Train PI objectives.

Business value must only be assigned to team PI objectives. The predictability metric itself is rolled up to determine predictability at a
higher level.

Figure 4. Roll-up of the team, ART, and Solution Train PI objectives

Reduce WIP with Realistic PI Objectives

During the team PI objectives review, not everything the various business stakeholders envisioned will likely be achieved in the PI timebox.
Therefore, some of the planned work will need to be reevaluated with Business Owners to gain agreement with the PI objectives.

Those lower-priority work items get moved back into the ART Backlog. Decreasing excess WIP reduces overhead and thrashing and
increases productivity and velocity. The net result is a feasible set of PI objectives agreed to by all business stakeholders and team
members, increased efficiency, and a higher probability of delivery success.

Planning at the large solution level can be very similar; the planning of the ARTs will impact each other, pushing some work back into the
Solution Train Backlog for re-evaluation in a later PI.

Learn More
[1] Leffingwell, Dean. Agile So tware Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-
Wesley, 2011.

[2] Reinertsen, Donald. e Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas
Publishing, 2009.

Last update: 13 December 2022

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the
express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for
permissions.

Framework Training Content & Trademarks Scaled Agile, Inc

Download SAFe Posters & Course Calendar FAQs on how to use SAFe content Contact Us
Graphics and trademarks
About Certification
5400 Airport Blvd., Suite 300
Watch and download SAFe videos Permissions Form
Boulder, CO 80301 USA
and presentations Become a Trainer
Usage and Permissions
Blog Business Hours

Weekdays: 9am to 5pm

Weekends: CLOSED

© 2024 Scaled Agile, Inc. Get News Privacy Policy Code of Conduct Remote Training Policy