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 effectively coordinate an Agile Release Train (ART) as a self-organizing, self-managing team of teams.
- Align the individual team members and the Product Owner to a common mission
- Align the individual teams to the program Program Increment (PI) Objectives
- Provide context for understanding and addressing cross-team dependencies
In short, they offer a simple communication protocol between the teams, management, and Business Owners that allows everyone to work toward a common purpose, while continuously apprising management of the work in progress.
Whether the teams apply Scrum or Kanban, iteration goals give program stakeholders, management, and Agile teams a common language with which to maintain alignment, manage dependencies, and make necessary adjustments during the execution of the program increment.
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 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 and necessary infrastructure
- Business or technical Milestones
- Architectural, technical, or infrastructure effort
- Routine jobs
- Other commitments, such as maintenance and documentation
Iteration goals are achieved by completing backlog items, even though it may not be necessary to complete 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 are a part of Scrum Extreme Programming (XP). (Scrum calls them the ‘sprint goals.’) ScrumXP teams do their work via stories that are purposely 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 Agile release train context, 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. They are fundamental to three of the four Core Values of SAFe: transparency, alignment, and program execution. 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 then be able to communicate it in business terms to the Business Owners, management, and other stakeholders.
Although Kanban teams don’t use iterations in the same way that ScrumXP teams do, when part of an ART, iteration goals still provide transparency and alignment.
As described below, iteration goals assure the three aspects of value that constitute a comprehensive approach to helping the teams and ARTs stay aligned and continually committed to a common purpose and mission.
Align Team Members to a Common Purpose
The execution of an iteration is a fast and furious process; two weeks can go by very quickly. Iteration goals help the team and Product Owner come to an initial agreement on the business value they intend to deliver, align with team and program PI objectives, and ground everyone in their agreed-to purpose, as Figure 2 illustrates.
Align Program Teams to Common PI Objectives and Manage Dependencies
Agile teams are not islands of agility. Rather, they are integral parts of the larger Program Level context and purpose. As a result, each team must communicate the intent of upcoming iterations to the other teams and to the Release Train Engineer (RTE). This ensures that they remain aligned to the program PI objectives. In addition, individual team iteration goals provide the necessary context for discovering dependencies and developing resolutions, as Figure 3 illustrates.
Provide Continuous Management Information
Scaling to the program level while remaining Lean and Agile depends on building self-managing, self-organizing Agile teams that require little management intervention or daily supervision. This allows managers to manage up and across, rather than down. This creates a leaner, more empowered organization in which management can handle more responsibility, using organization skills to eliminate impediments and drive improvements.
However, management cannot and should not relinquish its responsibility to understand what the teams are doing and why they are doing it. It is still accountable for the effectiveness of the development organization and the value delivery outcomes. To this end, aggregating iteration goals for a train provides a simple, textual, 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: 17 October, 2017