Sprint Zero: Don’t Waste Your Time

February 10, 2012

Is there such a thing as a Sprint Zero in Scrum? Should there be? After all, don’t teams need to decide on the tools that they’re going to use and set up important things like version control, build machines and app servers so that they can be productive during sprint work? One thing is for sure, we don’t have a shortage of opinions on the subject!

Ken Schawber flatly declares that “There is no such thing.” Ron Jefferies provides a balanced perspective at Scrumdevelopment@yahoogroups.com:
It's probably a good idea to get your computers set up before trying to write software, for example. It's probably a good idea to have at least a fair vision of what you are trying to build. It is probably not a good idea to define a lot of architecture and IMO it is almost certainly not a good idea to install your database and schema.

I do, however, object to calling those activities Sprint Zero. Here is my reason:

It is a core principle of Scrum that every Sprint must produce an increment of potentially shippable software.

Therefore, an interval of time which does not produce an increment of potentially shippable software is not a Sprint.

Therefore such a time interval should not be called a Sprint. It doesn't do what a Sprint does.
Now we’re getting somewhere… The Scrum Guide defines a Sprint this way:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
So… If you want to adhere to Scrum precisely, there is no Sprint Zero. The basic tenet of Scrum is to deliver potentially shippable software that has value to the customer at the end of every Sprint. But that doesn’t mean that important activities shouldn’t be taking place.

Teams shouldn’t rush to deliver working software without considering how the software will be versioned. It pays to have an automated build machine and app servers in place. The team should agree on the development tools that are going to be used. Without these things, teams will not be able to provide value as efficiently and effectively as they could.

This means that there is value in getting certain things done up front. This can in fact be a time-boxed interval that will enable teams to be productive when they start working on the product backlog. In an agile context, it is all about doing what is essential to start building small increments of valuable software as early in the game as possible. Don't waste time defining the entire database structure up front, let alone any type of Big Design Up Front based on Big Requirements Up Front.

Getting the right work done at the right time is what matters. If you can set up your development and QA machines with all the required tools and deliver an increment of working software along with that activity, congratulations! You’re being agile. If setting these things takes up all the time so that you can’t deliver any product, well, there’s value in getting those things done, right? So call that increment of time whatever you want – Sprint Zero is fine. And don’t waste any time debating over the name.