Can you imagine what I would do if I could do all I can?

– Sun Tzu

The process of creating, aligning and committing to meaningful short-term objectives is the single most critical factor in achieving agile program results.

–Dean Leffingwell

PSI/Release Objectives Abstract

PSI/Release Objectives are a summarized description of the specific goals and business values intended for the upcoming PSI(s). Objectives can be both inputs and outputs of Release Planning, but only the outputs reflect the team’s actual commitment. In order to ensure delivery reliability, many programs divide the objectives into two sets:

The committed set of objectives represents the high confidence delivery commitments that all program stakeholders can use for planning
And since estimating is inherently imperfect, stretch goals are those things the program hopes to accomplish in the timebox, but cannot commit to, due to the inherent variability of R&D

During release planning, each team synthesizes the vision and input objectives, defines initial user stories, and puts them into iterations until their capacity is allocated. They then use those results to reflect on the plan and synthesize and state the specific business objectives for the PSI. During plan review, business owners rank the business value of each objective on a scale of 1-10; that provides further guidance to the teams as to how to achieve the maximum business impact.

The aggregation of each team’s objectives becomes the program’s objectives, which are then summarized and published. In this way, all stakeholders know what to expect at the release boundaries, all work in process (WIP) is visible, and the program always has a current, aligned, definitive, and communicated set of business objectives.

Details

As the quote above calls out, the process of creating, aligning and committing to meaningful short-term objectives is a critical factor in achieving agile program results. In SAFe, this happens every 10 weeks or so, as an integral part of the Release Planning process. Indeed, setting such objectives IS the primary purpose of release planning, though there are many side benefits as well.

Objectives represent tangible and realistic intents that are fully understood and agreed to by the team and the business stakeholders. Figure 1 provides an example of one such set of objectives:

Figure 1. Example PSI Objectives with Plan vs Actual achievement comparison

They include all current commitments to value and are used for both planning and tracking.

The Purpose of Objectives

There are many artifacts and processes in SAFe; after all development at scale is a complex undertaking. However, much of that work can eventually be translated and summarized into a clear, succinct, always-current and agreed-to set of objectives for each team on a Release Train, and in aggregate, for the program itself. The purposes of setting and achieving PSI/Release objectives in SAFe are manifold:

To establish mission alignment amongst the teams and to identify dependencies that must be addressed to achieve the goals
To align development objectives with business mission, via summarized, rolling-wave forecast of program commitments
Decentralizing control (a primary theme of product development flow, see [Ref 4]). Moving the responsibility for planning and commitment from management to the teams empowers the teams and helps drive accountability and improve delivery velocity
To provide continuous guidance for individual teams iteration planning sprint goals, so that they constantly align to the program objectives
To provide a way to evaluate and improve program performance
To provide a quantitative, key program measure, the Program Release Predictability Measure.

What Are the Objectives?

During release planning, it becomes obvious that many objectives are simply the scheduled deliveriesy of high priority Features from the Program Backlog. After all, that’s why we manage value with that construct. But while they start there, they don’t end there, as there are a number of other considerations that can contribute to an objective set. These include:

Milestones, releases, tradeshows and other significant customer or business events.
Implementation of new architectural features, reduction of technical debt
Adherence to new and existing Nonfunctional Requirements
Advances to development and deployment infrastructure.
Completion and availability of new subsystems, components and services.
Completion and reporting of research activities
Advances in engineering practices, implementation of corrective actions and impediment removal

All of these aspects add additional context to the Program Backlog, Roadmap and Vision, which are all used to drive the release planning objective setting process.

Mapping Objectives During Planning

The transformation from the program backlog to Agile Team objectives is an interesting and somewhat non-deterministic process, as illustrated in Figure 2.

Figure 2. Features and other aspects drive individual team objectives

As teams break the features into Stories and load them on their sprint plans, they discover that some features require collaboration of multiple teams (Feature B in Figure 3); others may fully fit into one feature teams scope of work (Feature A). The former case has more interdependencies; the latter fosters more autonomous execution. Therefore, we strongly bias team composition into feature—as opposed to component—teams. But the mix of Feature and Component teams is determined both by the economics of reuse and the existing organizational structure, which can be evolved but not immediately refactored. In programs composed predominantly of feature teams, the team’s PSI objectives often relate directly to program features; the mapping is straightforward. In the case of component teams however, most every feature will appear on multiple teams’ objective sheets. Indeed without PSI objectives, component teams would not have meaningful, stated business-based objectives for the PSI at all. In addition, many larger features require the participation of multiple feature teams and component teams, so the mapping is not straightforward and dependencies are discovered and addressed during the planning process. Results of this process are captured in the affected teams objectives.

Stretch Objectives

In SAFe, stretch objectives provide a way to escape the tyranny of the iron triangle (fixed scope, resource and time, [Ref 1]) and help assure that system quality and the delivery timebox will be met, while using scope as a variable to ensure that key priorities are delivered. Teams commit to deliver on their non-stretch objectives and also agree to do their best to also deliver the stretch objectives, but realistically those may or may not be achieved in the timebox. Stakeholders know to plan accordingly. Figure 3 provides one example.

Figure 3. One team's objective sheet with one stretch objective

Stretch objectives provide the following benefits to the program:

Stretch objectives drive good economics. Without them, if the team must commit to a 100% scope in a fixed timebox, they are forced to build buffers into the system. Buffers convert uncertain “might-have-been” scope”, to certain, but “less-that-what-might-have-been” scope, resulting in less overall throughput.
Stretch objectives provide an estimating error allowance, thereby increasing the confidence in delivery of the main priorities. In turn, delivering commitments is the most important factor in building trust between the teams and the stakeholders.
In order to reliably deliver on a cadence, stretch objectives provide the capacity needed to alter priorities when fact patterns change

Typically, the total allowance for stretch objectives is 10%-15% of the total capacity. And we must constantly keep in mind that Stretch objectives are used to identify what can be variable within the scope of a plan; stretch objectives are not the way for stakeholders to load the teams with more than they can possibly do.

SMART Objectives

PSI Objectives serve as a brief summary of a team’s plan for the PSI. However, the fact that the objectives are at the higher level of abstraction means that they may tend towards fuzzy and non-verifiable “chunks of intent”. To address this, smart teams use SMART objectives. Each objectives is written in such a way that it is:

Specific. States the intended outcome as simply, 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 specified in a range
Achievable. Achieving the objective should be within the team’s control and influence.
Realistic. Recognize factors which cannot be controlled. (Hint: avoid making “happy path” assumptions)
Time-bound. The time period for achievement must be within the PSI, and therefore all objectives must be scoped.

Business Value

As the objectives are finalized, each objective is ranked as to business value by the business owners on a scale of 1-10. Business value should not be confused with any other measures, like the associated effort, total story points associated with an objective, etc. Business value is assigned, not calculated, and serves as an input to execution considerations.

Business value is intended to communicate the potential business effect of achieving an objective. The concept of business effect has been explored in techniques like business effect mapping (see Refs [2] and [3]). Business effect is a tangible result, meaningful from the business perspective and relevant to the key priorities of business. In assigning business value, business owners think through the business effects associated with the objective to determine its relative business value. So, for example, the objective of “introducing basic cross-selling functionality” to the ecommerce platform would result in the following anticipated business effects: a) increased sales in existing clients that use the platform (5%-15%), b) increased Net Promoter Score, c) extended client base.

In face-to-face conversation, business owners assign business value to each of the teams’ individual objectives. The value of this particular conversation, from business-to-team and team-to-business, cannot be overstated.

From Team Objectives to Program Objectives

The result of the release 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 program plan. (If not, planning continues until it is). In some cases, this is all the input the Release Train Engineer needs, and he or she uses that team data to roll up the diverse objectives into a cohesive presentation/statement for the upcoming PSI, one that is suitable for management communication.

Figure 4. A PSI planning board, showing key deliverables and dependencies between teams

However, as planning becomes more efficient in future sessions, the team may start to interactively build a Program PSI plan, as is illustrated in Figure 4. This plan indicates key feature delivery dates and other milestones and also highlights dependencies between teams that must be completed to achieve the plan. Such a plan can be posted in some prominent workspace, or captured in whatever tooling the program uses to record and measure progress against plans.

Objectives Drive Implementation Strategies

Another key benefit of objectives is how they improve ongoing sprint planning and execution strategies. Agile teams can identify what each objective requires and design the corresponding sprints and stories to effectively manage risk within the PSI (see Figure 5). As the objective is formulated, it is easier to see whether or not it requires certain infrastructure work, system redesign, new 3rd party components or libraries, input from clients or partners, research spikes, etc. This fosters more accurate planning for efficient incremental implementation, early risk reduction and also provides the ability to utilize stakeholder feedback early in the PSI.

Figure 5. Incremental implementation of an objective. WSJF prioritization parameters driven by the business value of the target objective.

Summary

The purpose of the SAFe framework is to improve economic outcomes for businesses that depend on software development. Conveniently, doing so improves the lives of users who depend on that software for their daily activities. Conveniently, doing so with agile methods empowers software development teams and makes their work activities more rewarding and more personally fulfilling.

All of this goodness depends on continuously aligning agile teams to a common mission. This is the purpose of PSI/Release Objectives.

Nothing in the framework is more critical.

Learn More

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

[2] Adzic, Gojko. Agile Product Management Using Effect Maps. http://gojko.net/papers/effect_maps.pdf

[3] Balic, Mijo & Ottersen, Ingrid. Effect Managing IT. Copenhagen Business School Press, 2007.

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

Last update 15 January, 2013