Clarity adorns profound thoughts.
—Luc de Clapiers
Iteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.
Iteration goals provide the following benefits:
- Align team members to a common purpose
- Align teams to common Program Increment (PI) Objectives and manage dependencies
- Provide continuous management information
Whether the teams apply Scrum or Kanban, iteration goals provide Agile teams, ART stakeholders and management with a shared language for maintaining alignment, managing dependencies, and making necessary adjustments during the execution of the Program Increment (PI).
As described in the Iteration Planning article, 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 to the work needed to achieve the team’s iteration goals
Iteration goals often reflect the following:
- Features, feature slices, or feature aspects
- Business or technical Milestones
- Architecture, infrastructure, exploration and compliance activities
- Routine jobs and other things, such as maintenance, refactoring and documentation
Iteration goals are achieved by completing backlog items, even though it may not be necessary to finish every story to meet the goals. In other words, the goals for the iteration override any particular story. On occasion, it may even be necessary to add new stories to achieve the iteration’s goals.
Why Iteration Goals?
Iteration goals support three of the four SAFe Core Values of alignment, program execution and transparency. Simply committing to complete a set of stories in an iteration is insufficient. The team must continually review the business value of each iteration, and then be able to communicate it in business terms to the Business Owners, management, and other stakeholders.
In the context of the ART, iteration goals help in understanding and maintaining a larger view of what the team intends to accomplish in each iteration, and what to present in the upcoming System Demo.
Although Kanban teams don’t typically use iterations for planning purposes, in the same way, that ScrumXP teams do, iteration goals are still required as they provide transparency and alignment, when they are part of an ART.
Align Team Members to a Common Purpose
The execution of an iteration goes by very quickly. It’s a fast and furious process. Iteration goals help the team, and Product Owner to reach agreement on the business value they intend to deliver, align their work to their team PI objectives, and ground everyone on their shared purpose, as Figure 2 illustrates.
Align Teams to Common Program PI Objectives and Manage Dependencies
Agile teams are not islands of agility. Instead, they are integral parts of the broader ART context and mission. As a result, the intent of upcoming iterations requires communication with other teams and the Release Train Engineer (RTE). Iteration goals facilitate alignment with the program PI objectives. Also, they provide the necessary context for discovering dependencies and developing a resolution, as Figure 3 illustrates.
Provide Continuous Management Information
Scaling agility depends on creating a leaner, more empowered organization in which management can decentralize more responsibility and focus instead on eliminating impediments and driving improvements.
However, management cannot and should not relinquish its responsibility to understand what the teams are doing and why they are doing it. Managers are still accountable for the effectiveness of the development organization and the value delivery outcomes. Aggregating iteration goals for a train provides a simple two-week summary of what’s happening, as Figure 4 illustrates.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 28 December 2019