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.
Characteristics of Sprint Zero
The main goal of a Sprint Zero is to deliver some usable value that can be built upon by the next team. Sprint Zeros are required to:
- Create the project’s skeleton, including research spikes.
- Keep design minimal.
- Develop a small number of stories to completion.
- Be low velocity and lightweight.
For this approach to work, there should be a few stories in the backlog prior to the start of the Sprint Zero — just enough for the Sprint to result in a product that can be demonstrated.
Goals, activities & benefits
To better understand what a Sprint Zero is and how it differs from a traditional Scrum Sprint, one must look at goals, activities and benefits of a Sprint Zero.
Sprint zero goals
Like a Scrum Sprint, the main goal of a Sprint Zero is production. But a Sprint Zero is not required to do as much intensive software development as a Scrum Sprint. In fact, Sprint Zero teams should keep it light as mentioned above.
More specifically, the deliverables of a Sprint Zero should be as follows:
- A usable piece of code, however small.
- A minimal environment for writing code.
- A prioritization of features or a list of stories.
- A release plan assigning each story to a Sprint.
- A plan for the most likely implementation of features.
Because the emphasis of a Sprint Zero is to ensure readiness for a Sprint, some organizations or projects will not need to incorporate this approach. If your company has been churning out successful Sprints in recent projects, you might already know your Sprint readiness situation without conducting a Sprint Zero.
Sprint zero activities
Just like other Sprints, Sprint Zeros should follow the same activities:
- Backlog updated
- Sprint planning session ensues
- Daily Sprint team meetings
- Sprint review sessions or debrief
- Deliverable product
- Sprint retrospective
The above list might look familiar because we’ve already talked about the process that takes place when teams undergo a Sprint. But unlike other Sprints, Sprint Zeros should not be longer than a few days; a week maximum.
Sprint zero benefits
The main benefit of a Sprint Zero is that it allows a team to get an idea of the work ahead of them. They can then self-organize in order to perform better in the long run. This also builds confidence in team members that they can handle the work to come.
When individuals go into a project without clarity, they are likely to become slowed at some point which could affect the success of a Sprint. Sprint Zero seeks to avoid this obstacle by offering an opportunity to plan a framework for success and ensure a working Sprint environment.
How to conduct a Sprint Zero effectively
To conduct a Sprint Zero effectively you have to go in with the understanding that a successful Sprint Zero means you’re ready to start Sprint One.“Ready” is a vague term and in this context, readiness does not refer to the availability of operation resources being in place (although hopefully this aspect is already taken care of). Readiness means that an environment exists in which development can occur.
Here are a few do’s and don’ts for conducting an effective Sprint Zero:
- Don’t take longer than a week.
- Do keep it lightweight and avoid big design principles.
- Don’t do more than is expressly needed for the first sprint to have a successful kickoff.
- Do work together as a team and emphasize a culture of team building.
Sprint Zero: not just pre-planning
Pre-planning is important to the execution of any project. Standard project preparations for software developers include gathering the right people and equipment to get the job done. But these steps do not characterize a Sprint Zero.
Unlike pre-planning, a Sprint Zero is not a project requirement. In fact, Sprint teams that are quick and efficient may never need a Sprint Zero. But for organizations new to Scrum, starting with a Sprint Zero should be the tipping point that engrains Agile principles of software development into an otherwise operational business culture.
