We stop at predetermined, unchangeable time intervals and compare reality to plan.
Iterations are the heartbeat of an XP project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they’ve pumped out working, tested software for each story and are ready to begin the cycle again.
Iterations are an important safety mechanism. Every week, the team stops, looks at what it’s accomplished, and shares those accomplishments with stakeholders. By doing so, the team coordinates its activities and communicates its progress to the rest of the organization. Most importantly, iterations counter a common risk in software projects: the tendency for work to take longer than expected.
Programming schedules die in inches. At first you’re on schedule: “I’ll be done once I finish this test.” Then you’re limping: “I’ll be done as soon as I fix this bug.” Then gasping: “I’ll be done as soon as I research this API flaw... no, really.” Before you know it, two days have gone by and your task has taken twice as long as you estimated.
Death by inches sneaks up on a team. Each delay is only a few hours, so it doesn’t feel like a delay, but they multiply across the thousands of tasks in a project. The cumulative effects are devastating.
Iterations allow you to ...