PI Objectives

Making and meeting small commitments builds trust. Ba must be energized with its own intentions.

—Nonaka and Takeuchi, The Knowledge-Creating Company

Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).

During PI planning, teams create PI objectives, which provide several benefits:

• Provide a common language for communicating with business and technology stakeholders

• Align the train with a shared mission

• Create the near-term vision, which teams can rally around and develop during the PI

• Enable the ART to assess its performance and the business value achieved via the Program Predictability Measure

• Communicate and highlight each team’s contributions to business value

• Expose dependencies that require coordination

Note: The Role of PI Objectives chapter in Part 9 explains the differences between Team PI Objectives and Features and provides additional insights on their usage and value.

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. However, PI objectives should not be confused with a set of fixed, inflexible, long-term deliverables.

For the business to do any meaningful planning, teams must do some amount of reliable, predictable forecasting. Too little, and critics will complain, “Those ARTs can’t commit to anything useful.” Too much, and critics will proclaim, “Those ARTs never do what they say they will.” Neither of these shortcomings is good, as both increase the distrust between business and development. That significantly hinders business success, not to mention the joy of work.

We need something in between—and that is a primary purpose of PI objectives. In addition to helping with alignment, the process of setting realistic objectives helps the organization avoid having too much Work in Process (WIP) in the system.

PI objectives and Iteration plans are built from the bottom up by Agile teams who estimate and identify their part of the solution during the PI Planning. They are summarized at the Program Level and then rolled up again at the Large Solution Level, if the ART is part of a Solution Train (Figure 1).

Three sections: solution PI objectives, program PI objectives, and team PI objectives are shown. The first section shows a note titled “radar POC” that reads, improve immersive experience and iOS App. The second section shows two notes. The first note titled “ride” reads, radar POC, improve, immersive, and experience. The second note titled “player portal” reads, iOS App. The third section shows four notes that shows the PI objectives along with business values. The first note titled “team A” reads, Radar POC (10). The second note titled “team B” reads, acceleration effect (8). The third note titled “team C” reads, deceleration effect (6), improve motion control (3), and acceleration effect (10). The fourth note titled “team D” treads, radar POC (4), and engine sounds (10). Four upward arrows from team A, team B, team C, and team D of team PI objectives points to ride of program PI objectives. Two upward arrows from ride and player portal of program PI objectives point to radar POC of solution PI objectives.

Figure 1. Roll-up of team and program PI objectives

Building the Team PI Objectives

During PI planning, the teams review the Program Vision and new features and plan the stories they need to deliver. In so doing, they also identify their specific team PI objectives.

Creating team PI objectives is not a trivial effort. It requires reasonable estimating and planning, a well-understood velocity, analysis of upcoming Features, definition of Stories for the Team Backlog, and, finally, summarizing of the information into simple business terms that can be understood by everyone.

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

Figure 2. A team’s PI objectives

Differentiate between Features and PI Objectives

The team’s PI objectives often relate directly to the system’s intended features; indeed, many objectives and features are the same. However, the mapping is not always straightforward, since some features require the collaboration of multiple teams (as shown in Figure 3).

The figure shows a stack of ten layers representing program backlog. An arrow from one of the layer points to feature A and arrow from the other layer points to feature B. To the right objectives of team 1, team 2, team 3, and team 4 are shown. Below this, the following feature aspects are shown: ASIC, board, FW, and validation. An arrow from feature A points to the objectives of team 3. Three arrows from feature B points to ASIC, FW, and validation. An arrow from ASIC points to the objectives of team 1. Arrows from FW points to the objectives of team 2 and team 4. An arrow from validation points to the objectives of team 4.

Figure 3. From features to objectives: Some features will appear on more than one team’s objectives

Note that some features (such as Feature A in Figure 3) can be delivered by individual teams; others (Feature B) require collaboration. In addition to features and inputs to features, other team objectives will appear in the mapping. These can include technical objectives (for example, the proof of concept in Figure 2) that enable future features, enhancements to development infrastructure, and Milestones. All the results of this process are captured in the affected team’s objectives.

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

The core question becomes, “Is our goal to complete the listed features, or is our goal to provide the outcomes desired by those features?” In other words, if we could provide the same value with half the amount of work, and without building all of the features, would this outcome be acceptable?

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

Use Stretch Objectives

Stretch 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 program’s predictable measures.

• Stretch objectives are used to identify work that can vary within the scope of a PI. Stretch objectives are not a way for stakeholders to load the teams with more work than they can do. They are not extra stuff to do, just in case time permits.

• If a team has low confidence in its ability to meet a PI objective, it should consider categorizing it as a stretch objective.

• If an item has many unknowns, consider moving it to the set of stretch objectives, and plan spikes early in the PI to reduce uncertainty about the team’s ability to meet the PI objective for that item.

Ultimately, teams agree to do their best to deliver the stretch objectives, and they are included in the capacity for the PI. Since these objectives might not be finished in the PI, however, stakeholders must plan accordingly.

Stretch objectives provide several benefits:

• Improved economics – Without stretch objectives, a team must commit 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 early completion of the work to certain late delivery, resulting in less overall throughput.

• Increased reliability – Stretch objectives have variable scope, allowing confidence in the delivery of the main priorities. In turn, delivering commitments is the most important factor in building trust between the teams and the stakeholders (stretch objectives are not committed objectives).

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

Typically, the total allowance for stretch objectives is 10–15 percent of the total capacity. The team must also constantly keep in mind that stretch objectives are used to identify what can vary within the scope of a plan.

Write SMART PI Objectives

Team PI objectives are a summary of a team’s plan for the PI. Sometimes this causes their description to consist of fuzzy and non-verifiable ‘chunks of intent.’ As a countermeasure, teams make their objectives SMART:

• Specific – State the intended outcome 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, so all objectives must be scoped appropriately.

Communicate Business Value with PI Objectives

As objectives are finalized during PI planning, Business Owners collaboratively assign business value to each of the team’s individual objectives in a face-to-face conversation.

The value of this particular 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) when assigning business value. Business value should not be confused with any other measures, such as the associated effort or total story points associated with an objective.

Thus, 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 (e.g., advances in infrastructure, development environments, and quality initiatives) allow for the faster creation of future business value. All of these factors must be weighed in the final balance.

Finalize the Team PI Objectives

When objectives have been made ‘smarter,’ stretch objectives have been identified, and business value has been established, then the objectives in Figure 2 might evolve to look like those in Figure 4.

The objectives of team A along with business value are as follows: proof of concept with mock sounds (10), help with radar POC (4), and decided to create or buy engine noises (3). The objectives of stretch are as follows: proof of concept with real sounds (7).

Figure 4. Objective sheet with business value and stretch objectives

Commit to PI Objectives

A vote of confidence is held near the end of PI planning, when the teams commit to the PI objectives. The commitment sought must be a reasonable thing to ask of the people who do the work. Therefore, the SAFe commitment has the following parts:

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

• The teams agree to escalate issues immediately that might prevent objectives from being met.

• During the course of the PI, if it’s discovered that some objectives are not achievable, the teams agree to escalate the issue immediately so that corrective action can be taken.

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

Creating Program and Solution PI Objectives

The result of the PI planning process will be some number of approved objectives, with one set of objectives for each team. 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 program PI objectives in a format suitable for communicating them to management.

The summarized objectives should be SMART, much like the team PI objectives, and have stretch objectives. Also, like the team PI objectives, these might be business Capabilities the ART is working on, enablers, or other business or technical goals.

During the Post-PI Planning meeting, after all the ARTs have planned, objectives are further rolled up to the large solution level by the Solution Train Engineer, and the solution PI objectives are synthesized and summarized. This is the top level of PI objectives in SAFe; such summaries communicate to stakeholders what the value stream as a whole will deliver in the upcoming PI. Figure 1 illustrates this summary from team to program and from program to solution PI objectives.

It’s important that business value is assigned only to team PI objectives. The predictability metric itself is rolled up to determine predictability at a higher level.

Reduce WIP with Realistic PI Objectives

During the review of the team PI objectives, not everything that was envisioned by the various business stakeholders will likely be achieved within the PI timebox. Therefore, some of the current in-flight development work (WIP) will need to be reevaluated in conjunction with Business Owners to gain agreement to the PI objectives.

Those lower-priority work items are moved back into the Program Backlog. Decreasing excess WIP reduces overhead and thrashing and increases productivity and velocity. The net result is a feasible set of PI objectives that are agreed to by all business stakeholders and team members, as well as increased efficiency and a higher probability of delivery success. That’s something that most everyone should be able to commit to.

Planning at the large solution level can work similarly. The planning of the various ARTs will likely create some conflicts, with some work being pushed back into the Solution Backlog for reevaluation in a later PI.

LEARN MORE

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

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