Sprint Zero


Starting a new project? A new product? Have a team transitioning to “Agile” (aka Scrum) and wanting to get ready?

Why not try a Sprint Zero? – Why not indeed.

Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc. etc.

Sprint Zero doesn’t need to happen in a time box, you can take all the time you need, after all, you haven’t become “agile” yet, Sprint Zero will make you Agile.

Good idea?

Please don’t.

Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further.

The truth is: there is work to do.

Just start “sprinting”. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.

Doing anything else delays the change and potentially reduces motivation.

If you want to call your first iteration Zero then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.

All those things I just listed – and more – that you need to do to “get started” are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?

If you haven’t worked out what those things are then No problem, try and schedule some real work. When you find you don’t have something (a database instance for example) simply write out a card, schedule it, do it. The things you need to do to “get ready” are actually things you need to do to build something you do want.

My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something – like install a database – when you could quite easily postpone that work for a few weeks or even skip it entirely.

Similarly some say “How can we start work until we know what we need to do? – we need to gather requirements, write some stories….”

But again: determining what needs doing, requirements gathering, is itself work to be done.

If it is not clear what needs to be done on day-1 then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.

Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things but once they are listed as part of the work to do – and especially if they have been promised to someone – then not doing them can be problematic.

Anyway, having written this blog I now wonder if I should have bothered. Now I look about a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.

4 thoughts on “Sprint Zero”

  1. Hi Allan, I think the concept of Sprint Zero came about at the start of projects where teams felt that Sprint 1 should result in a potentially releasable product, but they couldn’t commit to achieving this.

    High performing teams should be able to produce something, even if it’s just a fairly static web page or app home screen, and then build from there in subsequent Sprints.

    So, does it matter if the first one (or more) Sprints don’t result in a ‘potentially’ releasable product?

    1. Of course event sprint should result in a (at least one) releasable product but is it particlarly important if the odd one doesn’t? – Not in my book.

      A potentially releasable product is the aim of a sprint but sometimes it just doesn’t work out that way. If a team repeatedly fail to deliver (at least one) releasable product then there is a problem to be addressed.

      But missing the odd one?
      Missing the first one?


      Does that mean the team shouldn’t aim for a releasable product? No
      And they should feel bad every time they miss, otherwise they may stop trying.

  2. Why do we number sprints in the first place? Stop doing that. In a while you realize that you don’t need Sprints, just continous work. And then, all of a sudden, you realize you’re not sprinting, but actually running a marathon.

  3. Brilliant advice! I was once in a project where “sprint Zero” lasted for nine (9!) months. Actually, it may have continued even longer, but at that point, I quit.
    I think that too often, projects are started way too early, before we really know what we want. And as I think we both agree on, often they should be started at all. Just do things in the maintenance line instead!

    Thanks for always being a great source of inspiration!

Leave a Reply