None of my inventions came by accident. I see a worthwhile need to be met and I make trial after trial until it comes.
Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context.
Iterations provide a regular, predictable cadence for teams to produce an increment of value, as well as to refine those previously developed. These short time periods help the team, Product Owners, Product Managers, and other stakeholders regularly test and evaluate the technical and business hypotheses in a working system. Each iteration anchors an integration point, a ‘pull event’ that assembles various system aspects—functionality, quality, alignment, and fitness for use—across all the teams’ contributions.
Since the shortest sustainable lead time is a significant goal of Lean-Agile development, Agile teams execute a full plan-do-check-adjust (PDCA) cycle as quickly as possible. The PDCA learning cycle (shown in Figure 1) represents the following iteration events:
- Plan –Iteration Planning is the plan step
- Do – Iteration Execution is the do step
- Check – Iteration Review is the check step
- Adjust – Iteration Retrospective is the adjust step
Plan the Iteration
The iteration planning 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.
During this event, all team members collaborate to determine how much of the Team Backlog they can commit to delivering during the upcoming iteration based on the available team capacity. The team summarizes the work as a set of committed Iteration Goals.
Execute the Iteration
Iteration execution is the process of 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 work to the Product Owner as soon as they are done, enabling teams to arrive at the iteration review ready to show their completed work.
The daily stand-up (DSU) represents a smaller PDCA cycle within the iteration. Every day, team members meet to coordinate their activities, share information with each other about progress toward the iteration goals and raise blocking issues and dependencies. It is also common for Agile teams to spend some time during the iteration refining the backlog ahead of the next iteration planning event.
The iteration cadence occurs within a larger Program Increment (PI), which itself is another PDCA cycle. The PI aggregates the value developed by each Agile team and measures the solution under development objectively at relevant Milestones.
The iteration review is the ‘check‘ step in the PDCA cycle. This review is where the teams demonstrate a tested increment of value to the Product Owner, and other relevant stakeholders, and receive feedback on what they’ve produced. The iteration review provides the opportunity to assess progress as well as make any adjustments ahead of the next iteration. 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, the team prepares and participates in the System Demo that gives an integrated view of the new Features for the most recent iteration, delivered by all the teams on the Agile Release Train (ART). This demo serves as a ‘pull event’ to ensure early and regular integration and validation. Additionally, within the iteration, the system increment is continuously integrated and evaluated 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 reviews any improvement stories it had from the previous iteration. They identify new problems and their causes—as well as emphasizing bright spots—and create improvement stories that enter the team backlog for the next iteration. This regular reflection is one of the ways to ensure relentless improvement (one of the pillars of the SAFe House of Lean) is happening within each team. Iteration retrospectives may also identify systemic problems that will need to be addressed at the next Inspect and Adapt (I&A) event.
Before the next planning cycle begins, the backlog is refined to include the decisions from the iteration review and retrospective. The Product Owner refactors and reprioritizes new and old backlog items as needed.
Learn More Cockburn, Alistair. “Using Both Incremental and Iterative Development.” STSC CrossTalk 21, 2008.  Maurya, Ash. Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media, 2012.
Last update: 29 December 2019