I ran across the idea of an iteration zero today reviewing Peter Schuh’s Integrating Agile Development in the Real World. He defines it as:
An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices. … From a management point of view iteration zero may include
- Initial list of features identified and prioritized.
- Project planning mechanism identified and agreed upon.
- Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of iterative planning process, such as the time of planning meetings and the length of iterations.
I’ve used the iteration zero approach when setting up for a project before. A lot of times it takes a bit of prepping and planning to get some sort of initial product backlog together for the customer, finding a collocation space, and just getting some software installed.
There is a danger that you get too comfortable with this approach and you’re regularly beginning projects with an iteration zero that doesn’t really deliver actual value. I find most customers just aren’t ready to jump in day one on a Sprint unless they’ve spent some time thinking about the product backlog and what they probably want first. We’re using them less now that many of the teams are fairly familiar with Agile approaches, but they still happen.