Do you need a sprint zero?

What is a Sprint Zero?

The main objective of a sprint zero (aka iteration zero, inception sprint, etc.) is to get some quality items on a product backlog and set up some sort of minimal environment that allows you to have good quality code being produced. 

Some people have suggested that the sprint zero should be as short as possible, doing something that most people condemn when you talk about sprints or iterations, which is varying the length of iterations. This isn’t a problem at all and is part of how this idea came to be. 

Another way of seeing the sprint zero is looking at it as a planning iteration where you come up with a prioritized list of features and stories with estimates, a release plan that assigns the features and stories to the iterations, and a high-level application architecture, which is basically how the whole thing will be implemented when put together. 

How it came to be

The story is a bit imprecise, but short and sweet. The sprint zero has nothing to do with Scrum, and in fact it was invented or conceptualized by the people in the world of Extreme Programming in the early 2000s. It comes from the iteration zero, which was a new name for what used to be called ZFR, which stands for Zero Feature Release. It was basically a moment to make sure all the stakeholders involved knew that when this iteration is done, there will be no actual code produced. This iteration zero is time for the team to do other things. Apparently it was Mike Hill who introduced this idea in one of his Extreme Programming courses.

The pros and cons

The idea of a sprint zero really isn’t a bad one. It can actually be rather useful, although not without its problems.

The Pros

#1 Time to set up the environment

The sprint zero helps relieve the pressure of getting started producing right out of the gate. Products, projects, whatever it is you are doing can have a nice start where you have the time to sit and have a conversation about the why and how of things. Having a space for this kind of understanding is huge. I’m sure you are aware that once the team starts on the rhythm of sprint and iterations, more often than not, managers and stakeholders get agitated when you have meetings with nothing being delivered. It takes the pressure off and the team can start on a good note.

#2 Team and product workshop

During a sprint zero, you have the time for a full team workshop where you define the team agreement of how you want to work together as a team. It allows teams to set up their environments, technology, and do all of the prep work. 

#3 Make the set up a sprint goal

The idea of this sprint zero is to work on the organizational pieces of setting up the backlog and aligning with stakeholders if necessary. This setup is your sprint goal. The sprint zero then becomes an idea that is especially interesting for organizations that aren’t used to working in Agile approaches and this allows the team the space and time to really get started on a good note. 

The Cons

#1 Backlog prioritization starts with a sprint zero

It’s not an uncommon misunderstanding that the sprint zero is all the time you get, either as a product manager or as a team with a product manager, to create a full backlog and understand how the product fits in the rest of the organization and the product market. So, it’s really a lot of work confined to a small amount of time. All of these decisions on why this product is relevant, why now, why this team, what are the main chunks of work, etc. all ideally require some previous study. Ideally, you want your product manager to already have answers to these questions lined up so as not to be bombarded with questions that everybody feels they need to discover as they go.

#2 Setting up teams is a one-and-done thing

A sprint zero can make it seem that forming and preparing a team is a one-and-done thing. All the time you took to create your team charter, set up your infrastructure, that’s all you ever get as long as the team exists. But, as a great coach, you know that your team will constantly need to rethink their processes, behaviors, how they work, and look at past performance to improve for future iterations. You know that the architecture and tools we use to produce great code and products are always being updated and improved. A team needs time outside of just delivering features. A sprint zero can give the idea that you create a space in which you never come back, but in actuality it’s a constantly evolving thing. It’s great to have had the sprint zero at the start to get off on the right foot, but it doesn’t mean that in every single sprint you won’t be using some of your time to continuously improve your ways of working.

#3 Perfectionism

I feel that sprint zero kind of awakens the perfectionist in everybody. There is this idea that you must be entirely ready before you can start delivering something. It then becomes hard to define what “ready” really means. You might think that you need all possible information before you can attach a user story and deliver on that. Or that because your CI/CD could be missing a step or isn’t as fast as it could be, that you can’t proceed because you aren’t ready yet. It can allow for a lot of procrastination and the set up phase can become very long, especially if you are allowing your sprint zero to be as elastic as you need. 

#4 A sprint with no goal

A sprint zero can imply that you can have a sprint with no goal. But whether you are using iteration sprints or whatever, as soon as you have a cycle, you have to have an objective for it. Let’s say that maybe the objective is only related to the inner workings of setting up your backlog or technical infrastructure – that’s totally fine. But, you have to make this objective clear because at some point, you have to be able to say it’s done, let’s move on.

So do you need a sprint zero? No! It can be a very positive thing if you decide to use it, but of course there are some cons to look out for.