The Agile methodology provides a flexible, iterative approach to product development that prioritizes rapid adaptation and continuous delivery of value. This process is structured around a repeating cycle of work known as an iteration, which is often referred to as a Sprint in the Scrum framework. The cycle is defined by four distinct stages, each with a specific purpose, ensuring the team consistently builds the right product and improves its performance.
Understanding the Agile Iteration
An iteration is a fixed, short period of time designed to produce a usable, functional portion of the final product. This timeframe is known as time-boxing, which imposes a strict deadline to maintain focus and prevent scope creep. Iterations typically last between one and four weeks, with two weeks being the most common duration. The goal is to deliver a potentially shippable increment, which includes all completed and validated work from the current and previous iterations. This focus ensures that stakeholders can inspect working software at regular intervals, enabling rapid feedback and course correction.
Stage 1: Iteration Planning
The iteration begins with a planning session where the team determines precisely what work they will commit to completing in the upcoming cycle. The primary input is the prioritized Product Backlog, a list of all features, requirements, and fixes for the entire project. During this session, the team selects the highest-priority items from the Product Backlog that they believe they can successfully deliver, forming the Iteration Backlog. This selection process is informed by the team’s historical velocity, a measure of the average work completed in previous iterations, allowing for a realistic commitment.
The team collaboratively defines an Iteration Goal, a short statement describing the business purpose of the work. Selected items, often written as user stories, are then broken down into smaller, estimated tasks. Teams frequently use relative estimation techniques, such as story points, to size the complexity and effort of each item, rather than relying on time-based hours. The output is a finalized Iteration Backlog and a commitment to deliver the Iteration Goal by the end of the cycle.
Stage 2: The Execution Period and Daily Stand-ups
The Execution Period is where the majority of the time-boxed iteration is spent, as the team develops, tests, and integrates the committed work. During this time, every piece of code is written, reviewed, and tested against the agreed-upon criteria for completion. Continuous integration and testing ensure the work remains functional and stable, preventing difficult integration efforts at the end. The team’s progress is visualized, often on a physical or digital board, which clearly displays the movement of tasks from “To Do” to “In Progress” and finally to “Done.”
The Daily Stand-up (or Daily Scrum) is a daily synchronization mechanism held at the same time and place. This meeting is strictly time-boxed to a maximum of 15 minutes, often enforced by having attendees remain standing. Each team member quickly addresses three questions: what they accomplished since the last meeting, what they plan to work on next, and any current impediments blocking their progress. The stand-up is a forum for inspection and adaptation of the daily plan, not a problem-solving session; complex issues are deferred for discussion immediately after the meeting concludes. This rapid communication helps the team self-organize and adjust its approach to stay on track.
Stage 3: Iteration Review and Demo
The Iteration Review is a formal meeting that occurs at the end of the execution period to inspect the product increment and gather feedback from stakeholders. This session is focused entirely on demonstrating the working features that meet the team’s Definition of Done (DoD), which is the agreed-upon quality checklist for a completed piece of work. The team showcases the new functionality to the Product Owner, management, and other interested parties, allowing them to see the tangible results of the iteration. The demonstration should only include work that is fully completed and integrated, proving that it is truly part of a potentially shippable product.
The primary purpose is to solicit direct feedback on the product, which is then used to adapt the Product Backlog for future iterations. Stakeholders can confirm whether the delivered features meet their needs or suggest modifications and new ideas based on what they have seen. This inspection serves as a formal checkpoint to ensure alignment between the development effort and the overall project vision. The outcome is a revised Product Backlog with new priorities and potentially new items for the next planning session.
Stage 4: The Retrospective
Following the review, the team holds the Retrospective, an internal meeting dedicated to inspecting its process and performance. This is a private event for the development team and process facilitators, designed to foster psychological safety for honest reflection. The discussion centers on three main areas: what went well during the iteration, what challenges were encountered, and what changes the team should implement to improve its work.
The team analyzes its collaboration, tools, relationships, and technical practices without assigning blame or focusing on individual errors. The conversation leads to the identification of one or two concrete, actionable improvement items that the team commits to implementing in the very next iteration. By focusing on process improvements every few weeks, the team ensures it is continuously learning and optimizing its methods for greater efficiency and quality.
The Continuous Nature of Iterations
The four stages—Planning, Execution, Review, and Retrospective—form a continuous loop that drives the product forward and refines the team’s way of working. As soon as the Retrospective concludes, the team transitions into the next Iteration Planning session, restarting the cycle. The actionable items created in the Retrospective, such as experimenting with a new tool or changing a communication process, are often incorporated directly into the next iteration’s plan, ensuring that lessons learned are applied right away. This rapid application of feedback is central to the methodology’s adaptive nature.
Before the first cycle begins, a preparation period, sometimes called Iteration Zero, may occur to establish the foundational elements necessary for development. This initial effort involves activities like setting up the development environment, defining a high-level architecture, and establishing the initial Product Backlog and Definition of Done. This preparatory work ensures the team has a stable technical and procedural baseline, allowing the continuous loop of planning, executing, inspecting, and adapting to begin without delay.