Can you imagine what I would do if I could do all I can?
– Sun Tzu
There is more value created with overall alignment than with local excellence.
Program PSI Objectives Abstract
Program PSI Objectives are a summarized description of the business and technical goals for the upcoming PSI of an Agile Release Train. During release planning, each team reviews the vision and any other input objectives, defines initial user stories, and plans them into iterations until their capacity is reached. They then use those planning results to synthesize and summarize the specific business and technical objectives for their team for that PSI. These are the Team’s PSI Objectives.
Once a commitment has been reached, the Team’s PSI objectives are aggregated and summarized into the Program PSI Objectives, which is the subject of this article. In this way, all stakeholders know what to expect, all WIP is visible, and the program executes against a clear, aligned, and definitive set of program-level objectives. This helps assure alignment between the teams and the program, and between the program and the business. A the end of the PSI, the program assesses results against the objectives, and uses this input to continuously improve program performance.
The process of creating, aligning and committing to meaningful short-term objectives is a critical factor in building confidence between development and the business. These objectives also serve as the platform for continuously improving program results. Objective setting occurs routinely as an integral part of Release Planning. Program PSI objectives have a number of purposes, including:
- Align the program to the business mission
- Align all teams to a common mission and a commitment to a near term set of deliverables
- Expose and remediate excess work in process
- Help evaluate and improve program performance
- Inform teams’ Iteration Planning, so that Sprint Goals continually align to program objectives
- Provide planning and status input for portfolio management
The primary input to Release Planning is the Vision, which is typically expressed in terms of the top 10 current, highest priority Features. Therefore, most PSI Objectives will simply be features, but there are a number of other considerations that contribute to objectives. These include:
- Milestones, releases, tradeshows and other significant customer or business events
- Contributions to Architectural Runway including new Architectural Features
- Support and maintenance, reduction of defects and other technical debt
- Adherence to new and existing Nonfunctional Requirements
- Completion and reporting of research activities
- Advances in engineering practices and development infrastructure; knowledge sharing and cross training
All of these aspects add additional context to the Program Backlog, Roadmap and Vision, all of which are used as inputs to the release planning objective setting process. Therefore, while most of the objectives will simply be features from the program backlog, additional business objectives typically appear as well, as Figure 1 illustrates:
Setting Objectives During Release Planning
As described in Team PSI Objectives, both Team and PSI Objectives are determined during release planning. The planning process and the team’s known velocities are used to determine what is feasible for the upcoming period, and how the teams plan to go about delivering that value. The initial outputs of release planning include SMART, and well formed Team PSI Objectives. (Note, if you are not already familiar with that process, pelase review the article before proceeding here)
Towards the end of planning, and as illustrated in Figure 2, the individual Team PSI Objectives are aggregated into the Program PSI Objectives. The result is a summary set of objectives that serve to communicate the intent of the next PSI. This is a primary outcome of the release planning process, and is the basis for the program commitment.
Committing to Objectives Helps Shed Excess WIP
During review of Team PSI Objectives, it will typically start to become obvious that not everything that was envisioned by the various business stakeholders will likely be achieved in the PSI time box. Therefore, in order to gain agreement, some of the current in-flight development projects (WIP) will need to be re-evaluated. This happens throughout the release planning process, but is crystalized in the final agreement amongst all the stakeholders to the Program PSI Objectives. Those lower priority projects get moved back into the Program Backlog (a lower cost holding pattern, also called “not doing this now”). Decreasing excess WIP reduces overhead and thrashing, and increases productivity and velocity. The net result is a set of a feasible set of objectives that are agreed to by all business stakeholders, increased efficiency, and a higher probability of delivery success. And that’s something that most everyone should be able to commit to.
The purpose of the SAFe framework is to improve economic outcomes for businesses that depend on software development. 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, achievable business mission as reflected in an agreed to set of Team and Program PSI Objectives. But as opposed to traditional development, these objectives are set by the teams, not for the teams. And that makes all the difference.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Last update 16 July, 2013
© 2010-2013 Leffingwell, LLC. All rights reserved.