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.