Making and meeting small commitments builds trust.

—Nonaka and Takeuchi, The Knowledge-Creating Company

PI Objectives

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 are the things they intend to accomplish in the upcoming PI. These provide several benefits:

  • Provide a common language for communicating with business and technology stakeholders
  • Creates the near-term focus and vision
  • Enables the ART to assess its performance and the business value achieved via the Program Predictability Measure
  • 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, by its very nature, development is uncertain , the business depends on teams for some amount of reliable, predictable forecasting. Too little, and the business can’t plan.  Too much, and the business has committed to longer term plans, which are at best unreliable, and  also limit agility. Business and technology stakeholders need something in between, and that is a primary purpose of PI objectives. In addition to alignment, the process of 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 estimate and identify them during PI Planning. They are summarized for the ART, and can then be rolled-up to the Large Solution level (if needed), as shown in Figure 1.

Figure 1. Roll-up of the team and program PI Objectives

Building the Team PI Objectives

During PI planning, the teams get an update on new features and plan the stories they need to deliver. In so doing, they also identify and roll up their stories into their specific team PI objectives. Doing so requires estimating and planning, knowledge of the teams velocity, analysis of upcoming Features, defining Stories for the Team Backlog, and, finally, summarizing 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 intended features; indeed, many are the same. However, the mapping is not always straightforward, since some features require the collaboration of multiple teams, as Figure 3 illustrates.

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) can be delivered by individual teams; others (Feature B) require collaboration. In addition to features and inputs to features, other team objectives will appear as well. 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 team’s objectives.

Features and acceptance criteria are excellent tools to help 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 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/Engineering and Product Management and quickly finding ways to apply their expertise to create better solutions.

(Note: The advanced topic article Role of PI Objectives article explains the differences between Team PI Objectives and Features and provides additional insights into their usage and value.)

Committed and Uncommitted Objectives

Committing to a series of short term objectives builds trust into the system. Trust allows all stakeholders to move forward with confidence and to base decisions and plans on what is ‘very likely to be true very soon’.  But planning with confidence in the face of the uncertainty inherent in research and development is difficult. Things don’t always go as planned, and it’s simply prudent to build some small amount of buffer into the system. If the buffer is too big, then less might be accomplished that would otherwise be the case. If the buffer is too small, many commitments may turn out not to be feasible and planning and confidence erodes. To address, this SAFe recommends teams use both committed and uncommitted objectives during planning. (Note: these were ‘stretch’ objectives in earlier versions of SAFe). 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 program 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 simply not certain.  Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective. This 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 fairly critical objectives that the business is depending on and the team is already loaded to about full capacity.

In this case, a few uncommitted objectives are prudent. However, teams agree to do their best to deliver the uncommitted objectives, and they are included in the capacity for the PI. Since these objectives might not be finished in the PI, stakeholders plan accordingly.

Uncommitted objectives provide several benefits:

  • Improved economics – Without uncommitted objectives, a team is committing 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 the delivery of 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.

Typically, an allowance for uncommitted objectives might be 10-15 percent of the total capacity.

Write SMART PI Objectives

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

  • Specific – States 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, and therefore all objectives must be scoped appropriately.

Communicating Business Value with PI Objectives

As objectives are finalized during PI planning, Business Owners collaboratively assign ‘business value’ to each of the team’s 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) to rate each objective. They need not be ‘normalized’ across teams; every team has some highest priority (rated 10) items.

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 the faster creation of future business value. All of these factors must be weighed in the final balance.

Finalize Team PI Objectives

When objectives have been made ‘smarter,’ committed 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.

Figure 4. Team A PI Objectives with an uncommitted objective

Commit to PI Objectives

A vote of confidence is held near the end of PI planning, where the teams commit to the committed PI objectives. 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 course of the PI, if it’s discovered that some objectives are not achievable, then the teams agree to escalate immediately so that stakeholders are informed and 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 sufficient notice so as to be able 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 Program and Solution PI Objectives

The result of the PI planning process will be some number of approved objectives sheets, one per 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 management communication.

The summarized objectives should be SMART, much like the team PI objectives, and have uncommitted 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, and they communicate to stakeholders what the Solution Train will deliver in the upcoming PI. )Figure 1 above illustrates this summary from team to program and from program to solution PI objectives.)

It’s important that business value is only assigned 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 in the PI timebox. Therefore, some of the current in-flight development work (WIP) will need to be reevaluated with Business Owners to gain agreement to the PI objectives.

Those lower-priority work items get moved back into the Program Backlog. Decreasing excess WIP reduces overhead and thrashing, and it 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.

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 Backlog for re-evaluation 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.

Last update: 6 September 2019