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 11th 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.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. My view is that if you don’t plan to deliver some Working Software it is not a Sprint. Hence I don’t utilise Sprint 0.

    In my experience of having transitioned three companies from Waterfall to Scrum it is crucial to provide training, set the vision and do some backlog grooming/refinement very close to starting Sprint 1. This I normally do by just scheduling appropriate meetings and leaving the team members to use the remaining slack time however they feel is best.

    • Jim Bowes says:

      Thanks Andrew. I think you’re right.

      The exception for me is where there’s an over arching stage gate approach in a complex organisation.

      Some of Jeff Patton’s material about Agile discovery is really effective – assembling a small working group that represent value, user experience and what is feasible and organising other meetings as needed.

      Generally I use this and a few other tools at a pace that’s appropriate to the organisation I’m working with.

    • Vijay says:

      We do similar things in the name of Sprint 0, i.e., have as many as meetings / workshops upfront to understand about the epic / feature, do the required analysis, come up with stories, refine them and estimate them and then do the Sprint Planning for Sprint 1. If any time left during Sprint 0 then team will start with some development / test preparation activities upfront.

  2. […] tried the “sprint 0” and also working a sprint ahead of the software development […]

Sign up for the Manifesto newsletter and exclusive event invites