Clarity adorns profound thoughts.
—Luc de Clapiers
Iteration Goals Abstract
Iteration Goals are a high-level summary of the business and technical goals that the Agile Team and Product Owner agree to accomplish in an Iteration. Iteration goals are integral to the effective coordination of an Agile Release Train (ART) as a self-organizing, self-managing team of teams. They help align the individual team members and the Product Owner to a common mission for the iteration, align the individual teams to the Program PI Objectives, and provide context for understanding and addressing cross-team dependencies. Finally, they provide a simple communication protocol between the teams, management, and Business Owners, so that all are working toward a common purpose and management is continuously apprised of the work in process.
Whether the teams apply Scrum or Kanban, iteration goals provide program stakeholders, management, and Agile Teams with a common language with which to maintain alignment, manage dependencies, and make any necessary adjustments during the execution of the Program Increment (PI).
As described in Iteration Planning, the planning process produces three outputs:
- The Iteration backlog, consisting of the Stories committed to the iteration
- A statement of Iteration Goals, as shown in Figure 1
- A commitment by the Agile Team to the work needed to achieve the goals
Iteration goals often reflect the following:
- Features, feature slices, or feature aspects, such as research, necessary infrastructure, etc.
- Business or technical Milestones
- Architectural, technical, or infrastructure effort
- Routine jobs
- Other commitments, such as maintenance, documentation, etc.
Iteration goals are achieved via completion of backlog items, but it may not be necessary to complete every story to meet the goals of the iteration. In other words, the goals for the iteration trump any particular story. On occasion, it may even be necessary to add unanticipated stories to achieve the goals of the iteration.
Why Iteration Goals?
Iteration goals are mandatory in Scrum and SAFe (Scrum calls them the “sprint goals”). Agile Teams do their work via stories that are necessarily small enough to be completed in a single iteration. The ability to split user value into small, vertical, testable stories is essential to agility, but it can be difficult to see the forest for the trees. In the context of the Agile Release Train (ART), iteration goals help in understanding and maintaining a larger view of what the team intends to accomplish in each iteration, and what it intends to demo in the upcoming System Demo. They are fundamental to transparency, alignment, and program execution, three of the four Core Values of SAFe. Simply, committing to complete a set of stories in an iteration is insufficient; the team must be constantly looking at the business value of each iteration and be able to communicate that value in business terms to the Business Owners, management, and other stakeholders.
Iteration goals provide value in three aspects, which constitute a comprehensive approach to helping the teams and ART stay in alignment and continually commit to a common purpose and mission, as described below.
Align Team Members to a Common Purpose
The execution of a iteration is a fast and furious process, and two weeks go by very quickly. Iteration goals help the team and Product Owner come to initial agreement on the business value they intend to deliver, align to Team and Program PI Objectives, and help ground the team to their agreed-to purpose, as Figure 2 illustrates.
Align Program Teams to Common PI Objectives and Manage Dependencies
SAFe teams are not islands of agility. Rather, they are integral parts of a larger Program Level context and purpose. As such, each team must communicate the intent of upcoming iterations to the other teams and to the Release Train Engineer (RTE) so that they can ensure that they remain in alignment to the program PI objectives. In addition, individual team iteration goals provide the necessary context for dependency discovery and resolution, as Figure 3 illustrates.
Provide Continuous Management Information
Scaling to the program level while remaining Lean and Agile is dependent on building self-managing, self-organizing Agile Teams. These teams should require very little management interdiction or daily supervision. In that way, managers can manage up and across, rather than down. This creates an empowered, leaner organization in which management can handle more responsibility and use their organization skills to eliminate impediments and help drive organizational improvements. However, management cannot and should not abrogate their responsibility to understand what the teams are doing and why they are doing it, for they are still accountable for the efficacy of the development organization and the value delivery outcomes. To this end, the aggregation of iteration goals for a train provides a simple, textual, fortnightly summary of what’s happening, as Figure 4 illustrates.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update 14 October 2015