The benefits of applying Agile are clear and far-reaching. These include:

• Improved product quality
• Higher customer satisfaction ratings
• Increased control over project development
• Faster turnaround of ROI
• Fewer risks

Overall, Agile simplifies the project management process by breaking it down into easily manageable parts, or Sprints. It’s so effective that enterprise organizations are even beginning to apply the principles of Agile to project management across departments.

That said, as the demand for Agile grows, so has mystification around the term Sprint Zero. Most often, people think of Sprint Zero as applying the framework of a Scrum Sprint to the pre-planning process for a project whereby the pre-planning stage becomes a project in and of itself during the sprint. This is sometimes referred to as “the project before the project”.

However, this is an oversimplified, if not problematic, representation of Sprint Zero.

Understanding a sprint

In a Scrum Sprint, an assembled development team works on a clear goal to complete a piece of incremental and usable code over the course of a period of time, typically less than one month. The individual piece of code created is part of a larger project, and of itself can be tested and used.

Sprints must follow certain rules:

• Pre-determined quality goals must be maintained.
• Once a Sprint begins, no changes should be made that would prevent the goal from being delayed or completed.
• The scope can only be renegotiated between the Scrum Master and Product Owner.
• The Sprint should be between 2 to 4 weeks long.

When one sprint ends, the backlog is updated so that the process immediately starts again until the software development is completed and launched.

Debunking Sprint Zero myths

Before we talk about what a Sprint Zero really is, let’s talk about what it isn’t.

• A Sprint Zero is not the phase in which the team is put together. In order to conduct a Sprint in the first place, a team must already be in place.
• A Sprint Zero is not the phase for setting up infrastructure which should already be implemented or easily implemented on demand, but not as part of a Sprint Zero.
• A Sprint Zero should not involve adding products to a backlog or Consider Planning.

If you’ve heard about Sprint Zero, it is possible that it’s been presented in one of the above ways. However, all of the above steps should be accomplished in pre-planning phases, but not as part of any Sprint, even a Sprint Zero.

Consider Planning and adding items to the backlog during a Sprint Zero actually go against Agile principles that caution against big design up front.

Moreover, a Sprint Zero group is likely comprised of high level thinkers who may not be a part of other Sprints. If they take on the initial backlog setup this could result in an Agile organization being siloed into a hierarchy.

These aren’t the only ways that viewing a Sprint Zero like any other planning phase contradicts Agile principles.

Perhaps the most important rule of a Scrum Sprint is to produce usable code. By creating new rules for Sprint Zero teams that do not further the software development of a project, you are setting a precedent that rules don’t always apply. This results in teams that are less confident in what to do next.