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 are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox during which Agile teams deliver incremental value in the form of working, tested software and systems. They may last from one to four weeks, with two weeks as the suggested and most common duration.

Iterations provide the basic development cadence for Agile Teams building Features and components. During this short period, the team defines, builds, integrates and tests the Stories in their iteration backlog. Then, it integrates its output with that of the other teams, and prepares and participates in the System Demo. Each iteration is followed by another, providing the basic tempo of continuous value development and delivery.

The iteration cadence is the first 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), allowing them to plan togetherintegrate 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

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. Every two weeks, each team plans, builds, tests, integrates, and demonstrates their work in the context of a full system increment. 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 assembles 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 described by the Team PI Objectives, and to the outcome to be demoed at the Iteration Review and System Demos.

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. The specifics of the planning function, however, will differ based on whether the team works in ScrumXP or Kanban.

Execute the Iteration

Iteration Execution is the process for how the work takes place. During the iteration, the team completes the “Do” portion of the PDCA cycle by building and testing the new functionality. Teams deliver Stories incrementally, demoing their prepared 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, by the daily stand-up (DSU). 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 daily.

Iteration Review

The iteration review is the “check” step in the PDCA cycle. This is where the teams show a tested increment of value to the Product Owner and receive feedback on what they’ve produced. Some stories will be accepted; others will be refined by the insights gained during the iteration. The team will then do some final backlog refinement for the upcoming iteration planning.

Following the iteration review, 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 is the “adjust” 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 creates 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 immediately or at the Inspect and Adapt (I&A) event.

Before the next planning cycle 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: 8 June, 2017