The Structure of an Iteration

Iteration composition

Although Agile approaches differ in name, unit of work, and even the duration of iterations, the scribes are at least in agreement on what an iteration looks like. Each iteration is composed of three parts:

• Kickoff: Each iteration starts with a kickoff. Here, the team determines which work items will become part of the iteration. The quantity of work items selected is based on what’s attainable for the team. Not too many and not too few. The team will commit to these work items.
• Work: The main substance of an iteration is the realization of the agreed-to work items. This consists of analysis, design, construction, testing, and acceptance of the work items. Every day, the team’s progress is reviewed during the daily stand-up meeting.
• Evaluation: At the end of each iteration, an evaluation takes place with the whole team and the relevant stakeholders. The completed work items are evaluated. A demo is often performed. The team’s method is scrutinized, though. Is the quality up to par? Are we going fast enough? Can we get faster? Method improvements are carried out in the next iteration. During the next iteration’s evaluation, these improvements are naturally evaluated again.

Why iterations?

Working in iterations is a powerful tool. Many of the disadvantages of the Waterfall methods are neutralized. The main benefits, at a glance:

• Reduction of risks: Of course, we recognize that the same risks exist in Agile as they do in Waterfall. Even in Agile projects, the chosen software architecture can have limitations. The user interface may not be to our liking, or the performance can leave something to be desired. The software might not run in the production environment, and interfacing with other systems, services, and middleware may be complicated. The big difference between Agile and Waterfall is that all the work on the planned work items is performed in one iteration, so risks are identified much earlier. Not at the end of a project, but during the first few iterations. Anticipating risks at an earlier stage diminishes their impact enormously.

• Responding to change: At the start of each iteration, the work items that are currently the most important are selected. If new work items are identified during an iteration, or existing items are changed, they’re simply added to the backlog. If they prove to be important work items, we can prioritize them for the next iteration. In a Waterfall project, these are handled by creating change requests. They usually accumulate and are, at best, delivered at the end of the project. In Agile, if identified work items turn out to be unimportant they’re dropped before much time is spent on them.

• Collaborative roles: During each iteration, the selected work items are fully realized. Analysis, design, coding, testing, and acceptance of work items follow each other rapidly. Ideally, these happen on the same day. The various roles are no longer active in different phases of a project, as in Waterfall, but all at the same time. All roles benefit from each other’s knowledge and experience. Take the design of a work item as an example. On an Agile project, this often takes place during a workshop with the domain expert, the developer, and the tester together. Preferably even with input from the end user. Such a multidisciplinary workshop prevents mistakes before they can be made. This greatly increases the quality of the work items and the speed with which they’re delivered.

• Time boxes: How long it takes to realize a work item can’t be planned to the smallest detail. The rate of realization is occasionally slower than expected. There are occasional technical challenges. It is, however, unwise for iterations to last until all work items are realized. This is why iterations are carried out in time boxes with a fixed length. Work items that are unfinished at the end of the time box are placed on the backlog again. Working in time boxes prevents endless delays.

• The numbers tell the tale: The realization of individual work items makes the measurement of progress easy. A work item is ready (done) or not. Fairly binary. At any time in a project, one can determine how many work items are completed, usually counted in points. This accurate knowledge allows for timely and quick adjustments in case of delays.