What is a Sprint 0 and when you should (and should not) use it

What is a Sprint 0 and when you should (and should not) use it

There’s a concept rolling around called “Sprint 0”. There’s no ‘official’ definition of what this is from a Scrum Guide perspective. It’s simply not a part of Scrum.

Many in the Scrum world think the concept of, and the usage of, a Sprint 0 is a Scrum Sin. I agree, but I still do have a use for it

Where many use a Sprint 0 for is to dive deeper into analysis, requirements, and design. They take scrum sounding term and to do the same thing they did in their waterfall projects; a detailed requirements document, detailed design, full detailed backlog, and more. 

Some will take this Sprint to do things like training sessions, Agile exercises, team building. Some will dive into designs and mockups. Some will dive into detailed requirements. There’s really no guidance on how to use it. 

The fact is none of these produce value. According to the Scrum Guide;

By definition, a Sprint 0 is not a true Sprint. It has on Scrum lipstick, but it’s not Scrum. Many believe this is starting a team off on the wrong path. It promotes the idea that it’s ok to not deliver at the end of a Sprint. It doesn’t promote the value of Scrum properly. 

Scrum also works on empirical system;

Scrum says to just jump into Sprint 1. You don’t need a fleshed-out backlog to start a project or new team. You don’t need to understand all the requirements. You don’t need full designs and wireframes. You just need to start with the highest value, top priority work first. 

Spending too much time into these details is, by definition, a waste. Why?

With an empirical system, you want to take steps, learn, adapt, and repeat. It’s through the process you get better, refine more details, shift direction based on value, and build out a great product.

Most projects end up delivering something different than what was originally envisioned. So, spending time refining items lower in a backlog makes no sense. You might never get to those items, and even when you do, your context has changed and so will the details. You end up re-defining the story anyways.

By definition, I don’t disagree with any of my colleagues that don’t agree with a Sprint 0. Sprint 0 is not a part of Scrum. I dive into Sprint 1 in probably 99% of the projects I coach.

Where can you use a Sprint 0?

With all of that said, is there a place where a “Sprint 0” can be useful? I need to provide some history before answering.

With respect to a proper Scrum team, no – I don’t believe a Sprint 0 is necessary. The unfortunate reality is that most places are not doing proper Scrum. At least not at first.

When given the chance, I always want to promote proper Scrum technique. But as a coach, I understand I cannot change culture in a day. Often there’s steps needed to lead transformation in an organization’s people, culture, and behavior.

Many organizations are still creating and disbanding teams on a project basis. A team is stood up, operates for a term, delivers and is disbanded for a new team. Often times they are setup in a very waterfall way, expected to deliver within Agile (although it often smells very waterfall’ish) and the project “ends” at a point in time. Not really the best way to gain efficiency in the framework, but it’s a steppingstone in that many organizations take.

Without getting into too much detail on the problems of this approach, the major impact to success is that a team isn’t together long enough to gain efficiency in the framework. It typically takes a new team, regardless if it is made up of people with Agile expertise, at least 2-4 sprints before they get a stable velocity, understand the team dynamics and culture, go through a few retrospectives, and ultimately hit a stride of efficiency within Scrum. It takes time for the empirical system to provide results. It makes total sense.

In the case where teams shift fast and often, you lose the ability for a team to take it’s time to leverage the empirical process. You remove one of the core values of Scrum. So there isn’t any confusion, there is no substitute for a team gaining efficiency through the empirical process. A Sprint 0 won’t fix this.

I have however leveraged the concept of a Sprint 0 in some of these environments.

First, the Goal of the Sprint 0: The goal is not detailed design, it is not requirements generation, or anything like that. It’s a very quick context sharing. The ability for a team to get on the same page quickly, to be able to produce value quickly.

Agenda of Sprint 0:

The product owner and business explain the business problems

They provide context on the problems and the value they are looking to obtain. Context is shared on the background of the business unit, their work, and the specific business problem. Value is discussed that helps set a perceived goal or end point to the project

A high-level Product Backlog is created

This is not a complete backlog. The top (1-2 sprints worth of work) is detailed with at least Acceptance Criteria and Estimation (following INVEST). Anything further down might be larger Epics, that need to be refined later. The goal is, during Sprint 1 planning, the team has enough backlog to plan the Sprint.

Hidden value: The team gets an opportunity to meet each other

I’m less worried about events, games, or training. I’m more interested in the team getting a glimpse into who each other are, what each person brings to the table, and the dynamics of how communication will go. 

To repeat, a Sprint 0 is not Scrum. If given the choice I’d prefer the team to get this value out of using the empirical process properly.

BUT, when a team is put together for a short term, and that’s something you’re not going to change immediately, then a Sprint 0 could be a good, and temporary, strategy to inject context in a new team quickly.