When starting a new software version and/or embarking on a new product, what is the purpose of, and what are the crucial pieces of an "Iteration 0?"
It's important to realize that, in Scrum, there is no such thing as "Iteration 0" or "Sprint 0". All Sprints are the same and all result in a potentially releasable Increment.
However, Scrum isn't a complete product development life cycle. There are several early-life cycle activities that fall beyond the scope of Scrum as it's defined in the Scrum Guide. Some of these activities include obtaining funding for the effort, the formation of the team, the selection of Scrum as an appropriate framework, initial creation of the vision and first set of requirements (the first Product Backlog Items, in Scrum), set up of tools and infrastructure, verification and validation strategies, and perhaps the initial release planning.
These types of activities are typically done when launching a new product. I'm not sure that I would even consider an Iteration 0 in the case of a new version, unless that new version is not simply incremental improvements over the past version or if the team is launching for the first time.
Iteration 0 is a bit of a misnomer. There is no such thing in Scrum and it is often abused. So let me first start with the bad, then how I've seen it used well.
The problem is that in Scrum, the product is meant to be developed in increments with the result of each sprint being potentially releasable. Where this falls apart with an iteration 0 is when people use that time to do a large up-front design that the following sprints will slowly build out.
Where It Can Really Help
I know an agile coach who calls this a Hudson Bay start. For those readers who aren't Canadian, the Hudson Bay company used to run expeditions in colonial Canada. Before leaving on a long expedition, they would travel about a day out of their starting point, set up camp for a few days, and make sure all equipment and supplies were in good working order.
So applying this to Scrum, we would pick some product increment to build. I've worked with teams that use throw-away increments. The important thing is that they'll use the same environments and architecture as the real project. Then, in this first sprint, they will try to build something and "ship" it in the first sprint. Like the Hudson Bay expeditions, this drives out problems like permission errors, missing skills, license and plugin problems, etc.
Can you do an Iteration 0 and just focus on those same things that the Hudson Bay start brings out? Absolutely. The structure of the HBS just helps avoid dysfunction.
Also, you don't have to run an Iteration 0 at all if the team feels comfortable jumping in.
Every Sprint must produce a product increment, right? Working software. But when you start any project, you don't ever hit the ground running because you might need to prepare things: setting up the project and access rights, infrastructure work, buying and setting up servers, adding enough meat to user stories to actually be able to work on them, etc.
Sprint 0 or Iteration 0 was the name given to these preparation activities needed before you actually started to deliver something at the end of the Sprint. It was a "special Sprint" because you often didn't deliver much at the end of it. Why did it need to be "special"? Alistair Cockburn and Ken Schwaber had the following to say about it:
Alistair Cockburn remarked: I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented "Oh, that was Sprint Zero!" to get the peasants with the pickaxes away from his doorstep ... and then others thought that was a great answer and started saying it, too ... and then it became part of the culture.
Ken Schwaber offered the following observation in reply: Exactly ... sprint 0 has become a phrase misused to describe the planning that occurs prior to the first sprint ... and since planning creates artifacts that often change, it should be minimized prior to the first sprint, and then occur every sprint at the sprint review/sprint planning meeting (just in time planning)
Read more details in the following post (from where the above comments are taken): Scrubbing Sprint Zero.
Even if you are not doing Scrum, there is nothing special about an iteration 0...
In any Agile methodology, you deliver something of business value with each iteration - no matter how primitive.
This actually highlights both the benefits and weaknesses of Agile because it prioritizes delivery over planning - potentially at the expense of overall productivity...
In any methodology, there is always the trade-off between initial planning vs initial delivery: in a well-understood domain, planning up-front can result in a massive efficiency boost. Meanwhile, in a less well-understood domain, planning could be completely wasted due to unexpected events that derail everything.
Pure Agile prioritizes adaptivity & delivery over everything else, and treats each iteration as potentially the last. The result is that you will always get something of value from a project, but it may not be the best value for money - especially if you are operating in a complex domain that is well-understood by a well-known team.
In those situations, an Iterative development cycle based on an up-front planning and design phase will tend to deliver a much more efficient/effective level of productivity than pure agile!
The reason is that Agile relies on refactoring as a way to evolve the design - a design that is only intended to reflect the near-future, and not long-term goals (because In Agile, the long-term may not exist...).
Refactoring creates overhead due to re-work, and this re-work could be avoided in an iterative design/delivery plan that was optimized around a longer-term delivery approach that prioritized efficiency over regular delivery of features.
The relevance of this to Iteration 0 is that if you are doing pure Agile, you deliver something in iteration 0, even if you know it will bear no relationship to what is being delivered 6 months down the line!
The benefit of doing this is that you get to calibrate team productivity and velocity at a much earlier stage than you would otherwise, and in a high-risk domain, you can determine much earlier whether the project stands a chance of succeeding or failing.