I do believe in Sprint 0.

Lately I have been noticing some trends within the agile world that I don’t like at all. The first one is the market which the world of certifications has become, which has led some companies to make the mistake of assessing their level of agility ‘by weight’ according to the number of PSMs, PSPOs, PSDs, SPSs, PSKs, PALs, and so on.

The second trend – the one that I am more worried about – is the high degree of inbreeding in the industry and, hand in hand with this lack of openness, an excessive devotion to the Scrum Guide – with quasi-religious fervour.

I think the sector should already be mature enough to accept that methods are tools and not liturgy. But, most of all, to accept that there are other parallel worlds which are way ahead of agilism in some areas.

References outside the agile world

It is a fact that both startups and companies specializing in user experience know much more about product conceptualization than the agilist world and have devised their own methods for doing things.

From these worlds come different strategic design, product design, user validation and other techniques that have been optimized from a business standpoint by startups whose life literally depends on it.

According to this philosophy, we have examples like Google’s Design Sprint, Strategyzer’s Innovation Sprint, and even our own Rapid Prototyping Method for testing business ideas with real users using realistic prototypes.

And if we look into other disciplines – far beyond the world of software (yes, there is life beyond software) – we can also find many examples of this pattern.

Musicians and painters also use iterative and incremental techniques to create their works. However, they start with a small research phase that includes user validation, ideation, etc.

That is why I think it is dishonest for agilism purists to preach that there is no room for this type of techniques before the first sprint simply because they are not included in the Scrum Guide.

In my opinion, the use of these techniques at a stage prior to the first sprint is necessary, and I would even go so far as to say that not doing so is counterproductive in terms of the business.

So, where does the incompatibility lie?

I don’t agree with rejecting something just because it is not in the Scrum Guide. I believe that sprint 0, as well as other practices like TDD and Continuous Delivery – which aren’t part of the Scrum Guide either, fit perfectly with Scrum.

I understand that the philosophy behind the Scrum Guide is to serve as a broad – not detailed – work of reference for building agile products. It should work as a compass rather than a map, the details being left to teams that works according to the values described in the manifest.

The Scrum Guide gives a lot of leeway on how to create the Product Backlog and does not say that nothing can take place before the first sprint preparation meeting. Therefore, from that point of view, sprint 0 perfectly complements scrum on the product design plane.

The same Lean Startup stream even provides a solution on how to design the business model – after which the hypotheses would be validated with real users. Lastly, agile methods would be used to iterative build a digital solution.

Source: Steve Blank

We can say that something that is not in the Scrum Guide is not scrum – but this is not a bad thing per se or does not mean that it should be rejected. Is it really an antipattern? What’s the problem then? Is it simply the name?

If the problem is semantic in nature, I could care less if we use another name. The name sprint zero is quite self-explanatory and is easy to understand, but you can’t reject something good for purely semantic reasons.

I like the word sprint because I think it’s good to fix a short, delimited period of time in advance, although I personally think that design sprint or setup sprint are even better alternatives.

What is life like without sprint 0?

These techniques are used during a phase prior to software development and are useful to lay the groundwork for what comes next. We know that the environment in which we work is always changing and that any attempt to plan and try to predict the long-term future is a waste of time. But on the other hand, trying to put together a team and start building something without a high-level vision of what we are going to do is counterproductive.

A sprint 0 might be useful to reach the conclusion that you don’t need a new mobile app but rather to optimize an existing website so that it can properly be viewed on mobiles, or that the product you were thinking of selling to big companies is better suited to SMEs. Or even that making a product makes no economic sense and that it is better not to carry out more sprints.

And no, I’m not talking about a traditional analysis phase in disguise, with an excess of paperwork and planning, but about something that should be as short as possible, that follows agile principles and that serves to lay the foundations of what the digital product will be: business model, product vision, main functionalities, initial version of the backlog, etc.

On the other hand, there are people in the software world who think they work in an NGO or that money falls from the sky. In the end any new product needs to be financed, either internally by the company itself or externally if you are a startup.

In both cases I can’t imagine asking for this funding without some basic idea of what you’re going to build, without having defined the hypotheses you are going to test, without having a high-level release plan...

In the real world we can’t ask an investor to finance an idea that we don’t know how much it will cost, that we haven’t tested with users, that we aren’t sure what equipment it requires – to basically trust us.

Those of you who are against these techniques, how and when do you create the first version of the Product Backlog? How do you know what skills you need in your team if you don’t know what you’re going to build? Do you think these techniques could be applied in sprint 1?

Burn it at the stake!

I’m sorry to go against the grain, but I do believe in a sprint zero – by this or any other name – that covers a digital product’s strategic definition and vision – always at a high level – before going on to developing it.

I’d love to get your feedback. I’ll be happy to read your comments. I’ll keep an open mind to any way of doing things that is better, but l assure you that I’ve been using these techniques for many years now and they work for me – which I believe is what matters at the end of the day.