This post is from mountaingoatsoftware.com by Mike Cohn.
In my previous post, I wrote about alternatives to numbering sprints. In this post I want to deal with a very special number that some teams use in numbering their sprints–zero.
The concept of a “sprint zero” has become popular with some teams and so it is important to consider whether or not this is a good idea.
First, let’s agree on the basic premise of “sprint zero.” Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero.
One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product?
Click here to see the full post.
