In my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.

Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.

An iteration zero does not deliver any functionality to the customer. Instead, the project team focuses on the simple processes that will be required for the adoption and use of most agile practices. From a programming point of view the features delivered in an iteration zero may include:

  • Source control system installed and operational
  • Initial build script written and checked into source control
  • Initial promotion and deployment scripts written and checked into source control
  • Automated test framework selected and implemented with an empty test suite
  • Construction of a rudimentary continuous integration process

One good method of performing these activities is to rapper them around a “Log In” feature. (If the application does not have log-in functionality then a simple “Hello World” screen will do.) “Logging in” can then be the first piece of functionality to pass a test in the unit test framework. It can be the first thing to be automatically compiled, run through the continuous integration process, checked into source control, promoted to the testing environment, and automatically deployed.

From a management point of view, iteration zero outputs may include:

  • Initial list of features identified, estimated, and prioritized
  • Project planning mechanism (spreadsheet, simple database, index cards, or other planning tool) identified and agreed upon
  • Identification of and agreement upon a team customer, essential stakeholders and business users
  • Agreement on the initial approach to the iterative planning process (for example, the time of the planning meetings and the length of iterations)

The activities performed in an iteration zero are analogous to learning the letters and numbers of a foreign language. Before learning to read a foreign language we need to know how to pronounce the letters in that language. Similarly, before writing tests we need to have a unit test framework, and before prioritizing and planning features we need to have a simple system to track and organize those features. Finally, assigning this foundation-level activity to a single short iteration timeboxes the work, which guards against gold-plating, analysis paralysis, and a host of other project villains.

UPDATE: Want to read more thoughts on Iteration Zero. Check out An Iteration Zero for Project Recovery: Starting Again Without Starting Over

9 Responses to “Iteration Zero”
  1. [...] New Project Iteration Zero » Sep 01 [...]

  2. Great Post. I am tremendously inspired by it.

  3. That’s a good way of thinking about it. Handy to have a concise name for it also!

    What do you call bug fix only iterations or house cleaning iterations where you just focus on reducing technical debt?

  4. Most teams that I’ve worked with add tech debit and bugs into the feature catalog (or backlog) to be prioritized alongside everything else, so we almost never have iterations dedicated to these activities. I have heard arguments for dedicating an iteration to tech debt–or refactoring–but haven’t come across a name for it.

  5. Where is the best place to insert an iteration zero? Would it be before the recovery action, or is there a better place?

  6. Peter Schuh says:

    If I think the team is capable of it, I will institute a recovery Iteration Zero right away. If the team’s not ready, then after we’ve sorted some things out and gotten some management buy-in. I talk more about the timing of an Iteration Zero and project recovery in this post.

  7. I have never heard of an iteration zero, which is interesting as I work in a project based divison in a large Swiss bank. We usually have the first iteration of any project kicked off as iteration 1, and then subsequent iteration there after. I must say we do have tight deadlines so this may be the reason why.

  8. Great post, my team has recently commenced a more agile approach to the development of healthcare related software, we used iteration 0 but this caused confusion to a lot of people as they kept thinking but we’ve had 5 not 4 iterations. So we are thinking of calling iteration 0, iteration 1. Must say we have had some good results even though we have not yet implemented all of SCRUM.

    In fact we considering looking at DSDM as this appears more rigourous and structured than most other Agile methods and dovetails well with PRINC2.
    By the way any recommendation on how to do requirements gathering agile style e.g. use cases etc.
    Keep up the good work.

  9. Great article, liked the examples of tasks to do during the Iteration Zero and going through the delivery steps for “Log In” functinoality as the example of “acceptance criteria”.
    There can be also the acceptance criteria for management actions: e.g., the initial artifacts (Product Vision, working agreements) published to Wiki, identified features added to issue-tracking system and organized.

Leave a Reply

*
To prove that you're not a bot, enter this code
Anti-Spam Image