Scrum in practice: sprint zero

If you’re about to transition from waterfall to Scrum, or are assembling a Scrum team for a new project, you may well be considering kicking off with a ‘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. the 11^th of 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 0 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 0 which together form a discovery process. The sprint -1 would have a small core team that represent 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 LifeCyle).

You’ll often find these frameworks have stage gates in which budget is released to a project by aligning Sprint -1 and Sprint 0 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 in to 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 0 isn’t used for planning items in the distant future in detail. Instead it should be about setting 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 workout 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 having a project-before-the-project which adheres to Scrum values to e.g. 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 0 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 in to Scrum’s rhythm from the outset, but in some organisations this may be unrealistic.