What Is Sprint Zero?

The idea of Sprint Zero, like a lot of other things, has been used and abused. Assuming two-week sprints, and assuming that Sprint Zero is four weeks, let's examine some of what is claimed as Sprint Zero activity. 

Claim1: The team needs to be assembled in Sprint Zero. 

If team members have not been hired yet, there is no real way to get people in three weeks. It usually takes longer than three weeks to get resumes, develop a short list, conduct interviews, select, and bring someone onboard. If you do not have a team, you don't have a sprint. What's more, in many cases the new scrum team may simply be assembled from within the organization, in which case there is not much work being done to justify a sprint. 

Claim2: Organization and logistics need to be set up in Sprint Zero. 

I have not heard this view very many times, but some people have said this to me during conversations. Again, chairs, desks, workstations, SharePoint sites, etc., are important items, but these are really supporting activities to the real job of producing a feature or a product. These activities can happen any time or could be happening continuously in the background. A just-in-time approach will work just fine. For example, we can source monitors, software installs, etc., as people come on board. 

Claim3: Consider planning, product backlog setup, and design. 

This is my favorite, as it clearly indicates two things:

1. Someone is finding it hard to move away from waterfall.

2. The organization is finding it difficult to give up control and empower the team.

Introducing a long Sprint Zero at the start and a long validation at the end helps keep the love for waterfall alive. In addition, it hinders the effectiveness of scrum.

What Sprint Zero frequently ends up being

If waterfall works for you, then by all means, you should use waterfall. This article focuses on teams that follow the scrum rituals but keep the waterfall soul.

Scrum believes that every sprint should deliver potentially usable value. 

None of the above Sprint Zero items produce any value for the customer. They cannot be demoed. To be effective at scrum, we need to change our design thinking. In addition, there is no reason to be setting up logistics in Sprint Zero. In most organizations, there are separate groups that handle these things, and so the setup tasks can be assigned to someone to be done in parallel. Setting up logistics is not a story, it's a support task. A just-in-time completion of a support task works fine, even as advance completion may be welcome.

Considering planning, product backlog setup, and design in Sprint Zero is a proxy for "big design up front" (BDF). In agile we try to stay away from that. Often, an associated symptom will be a very hierarchical organization, thus preventing the scrum team from being really empowered.

• Personnel who are most active in Sprint Zero may be different from those most active in other sprints.

• The Sprint Zero leaders will "guide" the team through sprints but may not feel bound by the time and other constraints that the rest of the team has.

• This creates a two-level organization instead of the flat one that scrum promotes. A two-level organization tends to follow a task-assignment and status-reporting culture, instead of a mind-set of ownership and delivering value.

What Sprint Zero should be

Before we define Sprint Zero, let me say that the long system test phase before the release can actually be an automated regression test. Each sprint can create automated tests for the features it implements and add that to the regression. The need for automated tests is much discussed in scrum and agile literature, so we will skip it here for now.

Now for a working definition of Sprint Zero:

1. Sprint Zero should be used to create the basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes.

2. Minimal design up front is done in Sprint Zero so that emergent design is possible in future sprints. This includes putting together a flexible enough framework so that refactoring is easy.

3. For minimal design up front, the team picks up a very few critical stories and develops them to completion. Since these are the first few stories, delivering them includes putting the skeleton/framework in place, but even Sprint Zero delivers value.

Note: The velocity of Sprint Zero may be very low compared to that of other sprints.

Remember also that the product backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be begun during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero's start, enough to help us demo at least one working feature.

For more agile tips, go here.