Sprint Zero: A Good Idea or Not?

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?

I find that many of these things that can be used to argue for the need for a sprint zero are really best thought of as things that happen in what I call the project before the project. Before a development project begins, there is often a project to decide if there should be a development project. Before a company begins a major new initiative, someone has to think about whether that initiative should be undertaken at all.

Making that decision can be viewed as a project.

Since Scrum works well as a general purpose project management framework, it can be used to manage the work of this project-before-the-project. During this project-before-the-project, the early team members (perhaps just a future product owner) can work toward creating an initial product backlog, finding or hiring team members, setting up the technical environment, and so on.

I find it helpful to think of this work as a project of its own because it is not hard to imagine this work taking longer than one sprint, the special sprint zero. What does a team using a sprint zero call their second sprint if they need one to do whatever work they've used to justify the special type of sprint? Is it sprint 0.5?

A couple of cautions are necessary at this point:

• Keep any "project before the project" as lightweight as possible. Most development projects do not need a project before they begin.
• Remain true to the principles of Scrum. A team participating in a project before the project will not be able to have anything potentially shippable. That's fine. But understand why having something potentially shippable is a central tenet of Scrum and apply that in a honest way to the project before the project.

I wrote more about this last topic--staying true to the principles of Scrum on a project-before-the-project--here.