At a high level, Agile is a methodology for developing software that delivers potentially shippable working code in short iterations, while providing the flexibility to manage uncertainty and adapt to changing requirements. The benefits of applying Agile are real and pervasive, including:

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

It works by breaking software projects down from large feature sets into smaller bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two-week iterations called sprints.

Analysis, design, coding, and testing are continuous activities that continue for the duration of the project.

And as the demand for Agile grows, so has mystery around the term Sprint 0…

Debunking the Myths of Sprint 0

Let’s talk about what Sprint 0 isn’t before we dive into what Sprint 0 really is…

• Sprint 0 should not be focused on product strategy
• Sprint 0 is not the phase in which the team is put together – a team must already be in place
• Sprint 0 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 0

Just remember that all of the above steps should be accomplished in pre-planning phases, but not as part of any Sprint, even a Sprint 0.

What is Sprint 0?

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.

If you utilize Sprint 0, then the priority should be on getting the deliverables (outlined in this post) completed and a few user stories validated and ready for development in Sprint 1.

Since Sprint 0 is typically 1 week, don’t worry about doing any development. However, if the team can validate a couple user stories early in the week, then consider developing those to completion just to get the team into the development rhythm. Typically the Sprint 0 velocity will be very low compared to other sprints – don’t worry, you’re still delivering a ton of value!

Also, I prefer more preparation than less, so consider taking 2-3 weeks if necessary in order to be fully prepared for Sprint 1, especially if you’re a new team.

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 0 typically involves the following:

• 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 feature/function that can be demonstrated.

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 (Monday – Friday).

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

Team Norms – Discuss how the working board is organized and how supporting resources will be used. Establish the team norms for the flow of information / story cards. (e.g. working board status columns, what defines ready-to-work and ready-to-test story cards, etc.).

• Working Board (JIRA)
• Folders / Confluence Site
• Definition of Ready
• Definition of Done

Story Cards – Discuss the needs for writing story cards and what is required for “ready” status. Walk the team through the process of estimating and pointing story cards. (e.g. Description, Acceptance Criteria, Story Points, etc.), where I highly recommend reading my post on streamlining Agile estimation before you begin.

• User Story Writing
• Estimation & Story Pointing

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!

Continue reading about the specific team roles & activities during Sprint 0 >