Sprint 0 is a myth

Sprint Zero is becoming a very popular practice in the organizations where Agile and Scrum are used. Sprint Zero is not a part of the official Scrum framework, where it is mandatory to have a working and usable increment of the software at the end of the regular Sprint. Therefore there is no official definition for Sprint Zero even considering there are plenty of articles on the topic.

I am not a great fan of the Sprint 0 concept. Before we talk about what a Sprint Zero really is, let’s talk about what it isn’t.

• Sprint 0 should not be focused on product strategy
• 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.

Sprint 0 is a myth; a sprint should always result in at least one usable Increment.

The one concept that is most commonly cited to deal with initiation work is Sprint 0. This is not a formal part of Scrum, but the term is often used to describe the period of work when initial requirements, architecture, plans and the development environment are established. Thus, it is generally argued, Sprint 0 may be the one iteration in which a team may perhaps not deliver any tested code.

WHAT IS SPRINT 0?

A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release. There is nothing bad in doing that as long as everyone concerned has clear that the plan is subject to change as more is known as a result of the inspection of the sprints outcome. To sum up, that activity does not meet the definition of a Sprint in Scrum, so it is better not to call it so.

Sprint 0 is an awesome way to continue preparing an Agile product team for Sprint 1, typically through a “mini” sprint (1 week) to get the team together, finalize the last few product artifacts, and start user research, design, and development.

The goal of Sprint 0 is to be fully prepared to hit the ground running in Sprint 1 with a prioritized backlog, a few user stories that have been validated via user research, and all of the business and design artifacts completed.

PROJECT MANAGEMENT ACTIVITIES

One great thing about Sprint 0 is that it helps to focus on the needs of the team, where you should — at a minimum — cover the following project management activities during the Sprint 0 Session…

Scrum Ceremonies — Your team should review and decide on the Scrum Ceremonies, and schedule them accordingly:

• Daily Standup
• Sprint Planning
• Sprint Grooming
• Sprint Review (Demo)
• Sprint Retrospective

SOFTWARE DEVELOPMENT ACTIVITIES

Just like other sprints, Sprint 0 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 0 is typically 1 business week .

Characteristics of Sprint Zero

The main goal of a Sprint Zero is to deliver some usable value that can be built upon in Sprint 1, in addition to planning and preparing the team for future sprints. Sprint Zeros are required to:

• Create the project’s skeleton, including research spikes.
• Complete project management activities (e.g. team norms, ceremonies, etc.)
• 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 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.

CONCLUSION

Sprint 0 is especially important for teams that are new to Agile, or for products with a lot of complexity that require further exploration before Sprint 1. Or simply to give teams a chance to get to know each other and collaborate on something smaller before diving into the full sprint cadence. Just remember that if you don’t have a Sprint 0, then all of the deliverables mentioned above need to be completed in the Strategic Product Planning process.

With everything completed in the Strategic Product Planning and Sprint 0, your product team will be ready to hit the ground running on the first day of Sprint 1!

The Sprint Zero is not a silver bullet. It does not guarantee estimation accuracy and plan precision but it does give great momentum for developers and business. It will provide transparency from the very beginning enabling all participants and key people to be on the same page and thus reducing the number of potential miscommunications, misunderstandings, mis-, mis-, and mis’s …..

References: dsruptr.com, BMC, Scrum.org & agil8

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook