Iteration Types

What is an iteration in the Agile world? How is it different than previous ways the software community has performed iterations? Are there different types of iterations, and does it matter? The ScrumDevelopment list has been recently discussing type A, B, and C sprints (sprint = iteration in Scrum terminology) as defined by Jeff Sutherland and the ideas are relevant the the wider Agile community.

A majority of the Agile community would probably agree with the following definition of an iteration:

An Iteration is a constant time-box where the development team builds a part of the system completely as defined by the Done State. This allows the team to learn by taking a concept from requirements to as-close-as-possible to deployment and gives true visibility into project progress.

Furthermore, iterations run consecutively, the end of one iteration is immediately followed by the beginning of the next. This definition of iteration is different from earlier (pre-Agile) definitions mainly because of the Done State - pre-Agile iterations would build different parts of a function over multiple time-boxes without reaching completion.

So, from that basic understanding, here are three types of iterations as defined by Jeff Sutherland in Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. This is their representation graphically:

The main difference is their overlapping. Type A has a 'breather' between iterations/sprints to give the team a chance to agree on the previous done-ness of one sprint/iteration while giving a time window for the requirements to be communicated and agreed upon for the next sprint.

Type B resembles the definition of iteration above. There is a little overlap of the work for sprints as the product owner/customer prepares requirements for the upcoming sprint/iteration to be finalized in the kickoff meeting for the next sprint/iteration.

Type C is used in program management to run multiple related product scrums concurrently. It seems to show the overlap in an organization that uses Scrum of Scrums. If this seems confusing or unclear, you are not alone; Serge Beaumont attempted to clarify the differences after Jeff Sutherland visited his organization.

So how is this important to the Scrum community and the larger Agile community? Some, like Ken Schwaber, believe this takes our focus away from really important issues:

I've been following the threads about type N, A, B, C and advanced Scrum. Although these may represent the engineering, personnel, and product management practices that an organization adopts as a result of Scrum's inspect and adapt, they aren't Scrum. I think we are mistaking the consequences of Scrum with Scrum itself. What may be most destructive about these supposed extensions is that they will divert people from the real work of Scrum ...