None of my inventions came by accident. I see a worthwhile need to be met and I make trial after trial until it comes.

—Thomas Edison

Iterations Abstract

The Iteration is the basic building block of Agile development. Each iteration is a fixed timebox wherein the teams build an incremental element of business or product functionality. SAFe’s two-week iterations provide the basic development cadence for Agile Teams building Features and components. During this short period, the team executes the Stories in their iteration backlog, integrates the output with that of the other teams, and prepares and participates in a System Demo. Each iteration is followed by another, providing the basic tempo of continuous value development and delivery.

The iteration cadence is the first cadence in SAFe, but SAFe also provides a nested harmonic of short iterations grouped into a longer Program Increment (PI) timebox. This timebox provides the outer cadence for all the teams on an Agile Release Train (ART) to be able to plan together, integrate and demo together, and learn together.


Since fast learning is the key goal of SAFe’s Learning Cycles, Agile Teams execute a full Plan-Do-Check-Adjust cycle as quickly as possible, as illustrated in Figure 1.

Figure 1. PDCA in Iterations
Figure 1. PDCA in Iterations

Each PDCA cycle is an Iteration, which serves as the regular, predictable development cadence to produce an increment of value, as well as to refine previous increments. Each team plans, builds tests, integrates, and demonstrates their work in the context of a full system increment every two weeks. These short iterations help the team, Product OwnersProduct Managers, and other stakeholders test the technical and business hypotheses on a working system. Each iteration also anchors an integration point, a “pull event” that pulls together various system aspects—functionality, quality, alignment, and fitness for use—across all the teams’ individual contributions.

Plan the Iteration

The Iteration Planning meeting is the “Plan” step of the PDCA cycle. It aligns all team members to the common goals of the team, as described by the Team PI Objectives, and to the outcome that will be demoed at the Team and System Demos.

While the specifics of the planning function will differ based on whether the team works in ScrumXP or Kanban, the team reviews the Team Backlog and comes up with a set of Iteration Goals, detailing—from a system perspective—what will be ready for integration and demo by the end of the iteration.

Execute the Iteration

Iteration Execution is the process of how the work takes place. During the iteration, the team completes the “Do” part of the PDCA cycle by building and testing the new functionality. Teams deliver Stories in an incremental fashion, demoing ready stories to the Product Owner as soon as they are done; they arrive at the demo ready to show their progress.

During execution there is also a smaller PDCA cycle, as represented, in part, by the daily stand-up. Every day, team members meet to evaluate their progress toward the iteration goals and update each other on their progress. This meeting represents a full, daily PDCA cycle, which allows the team to plan, check, and adjust their iteration plan every day.

Team Demo

The team demo is the “check” step in the PDCA cycle. In the demo, the teams show a tested increment of value to the Product Owner and receive feedback on what has been produced. The outcome of this meeting will help shape the team backlog for the next iteration. Some stories will be accepted and others refined by the learning gained during the iteration.

Following the team demo, team members participate in an integrated system demo. This is the first required, formal integration point among teams on the Agile Release Train (ART), and it serves as a pull event to ensure early integration and validation at the Program Level. Within the iteration, teams integrate and evaluate as continuously as their system context allows.

Improve the Process

The Iteration Retrospective serves as the “check” step for the overall iteration. Here, the team evaluates its process and any improvement stories it had from the previous iteration, identifies problems and their root causes as well as bright spots, and comes up with improvement stories that enter the team backlog for the next iteration. This frequent retrospective is one of the key ways to ensure that relentless improvement (one of the pillars of SAFe’s Lean-Agile Mindset) is happening at the Team Level. Iteration retrospectives also drive program level changes to process either immediately or at the Inspect and Adapt workshop.

Before the next planning begins, the backlog is refined to include the decisions from the demo and retrospective. The Product Owner refactors and reprioritizes new and old backlog items as needed.

Learn More

[1] Cockburn, Alistair. “Using Both Incremental and Iterative Development.” STSC CrossTalk 21 (2008): 27 – 30.

[2] Maurya, Ash. Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media, 2012.

Last update: 13 April 2016