Scrum in practice: Sprint Zero

What is Sprint Zero?

In Scrum, there’s no prescribed way of naming each sprint. So while some teams like to use the end date of the sprint (e.g. 11 September sprint) or a shortened version of the sprint goal (e.g. the registration form sprint) most opt to number their sprints, starting with sprint 1.

Some organisations adopt the practice of having a sprint zero before the project actually kicks off for real. During this time the Scrum team might be assembled and technical issues like hardware, software and colocation issues sorted out.

Sprint zero might also be used in some organisations to train and coach a team that is entirely new to Scrum so that they’re familiar with the basic concepts, can experience the new working rhythm etc. It might also be used to populate the product backlog with a few high-level items in preparation for the first sprint planning meeting.

There are also teams that have a sprint -1 and a sprint zero which together form a discovery process. Sprint -1 would have a small core team that represents the user, business value and what is possible.

In larger organisations with a primarily waterfall approach, I’ve also found the sprint -1 and Sprint 0 concepts useful for aligning with overarching project management frameworks or SDLCs (System/Solution Delivery LifeCycle).

You’ll often find these frameworks have stage gates in which the budget is released to a project by aligning sprint -1 and sprint zero with some deliverables. Using this process you can actually help organisations become more agile — rather than letting them run a Waterfall pre project which then goes into an Agile delivery. But this is a big topic and I’ll deal with it in its own right in the future.

Common sprint zero pitfalls

It’s important that a sprint zero isn’t used for planning items in the distant future in detail. Instead, it should be about setting a vision, creating an initial backlog to meet that vision and getting initial estimates against it.

Teams new to Scrum or transitioning from Waterfall methods often struggle with the balance of what we work out now and what to work out iteratively. A good Agile discovery process before attempting to deliver software is crucial.

Getting the most out of sprint zero

There are a number of different approaches to sprint zero advocated by Scrum practitioners. Mike Cohn recommends dispensing with sprint zero and instead of having a project-before-the-project which adheres to Scrum values to assemble a team, put together a product backlog, etc.

Others recommend having a very short sprint zero during which just a few preparatory goals like putting together a backlog are accomplished.

Others still favour a longer than normal sprint called sprint zero at the end of which the team should produce a working increment of the product, as in any other sprint.

Whatever solution you opt for the main thing to keep in mind is that the goal of a sprint is to deliver value.

My view is that you need some time either through a sprint zero or another Agile discovery process to ensure that you have a backlog for the product or the release you’re working on, that the team you need is assembled and that your tools and environments are up and running. You must also have definitions of 'ready' and 'done' and enough stories that meet the definition of 'ready' for your first sprint.

Establishing the sprint pattern to achieve this can be a good way of creating focus and getting into Scrum’s rhythm from the outset, but in some organisations, this may be unrealistic.