Many development teams, especially those who are new to Scrum, or those trying to bring some level of agility to an otherwise conservative waterfall organization, struggle with their first attempts at adopting a truly agile approach. This is particularly true for teams getting started on a new green-field project. For these teams, one of the greatest hurdles to success is the imperative to deliver “something” at the end of just one sprint. The most common solution that these teams arrive at is having what is often called “sprint zero”. Unfortunately, this is a bad choice that hinders the team’s agile transformation; worse, its harmful effects materialize much later in the project.

What is Sprint Zero?

“Sprint Zero” is the name commonly given to a period of time that comes before a development team’s first “real” sprint. This period of time is often longer than the “real” sprints that will follow. Its primary characteristic, however, is that it breaks one of Scrum’s core principles. In sprint-zero, a team will do a lot of preparatory work, including research, experiments, design, architectural, and infrastructural work, but ultimately deliver nothing that the customers would consider “valuable”. The Scrum guide defines a sprint as “a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created”. In sprint zero, no such increment is created.

What is the Purpose of a Sprint?

The Scrum guide’s definition of a sprint has two parts to it, both equally important:

1. A time-box of one month or less

2. Create a “done”, usable, and potentially releasable product increment

At its root, like all other Scrum practices, the sprint’s purpose is to provide actionable feedback to the organization: making sure that you are building the right thing, and making sure that you are building the thing right.

The product increment provides something for the stakeholders to evaluate so that they can provide feedback: Is this what we asked for? Is this what we actually need? Is it performing adequately? Bottom line – do we “pivot” or “persevere”?

The time-box allows for the feedback to be actionable and timely, enabling the development team to react to the feedback before it is too late, i.e. the project’s deadline has arrived.

In short, the purpose of the sprint is to make sure that teams are progressing in a timely manner, and in the right direction.

So What is Wrong with Sprint Zero?

By now, the primary flaw of sprint zero should be fairly obvious: without the constraint of having to produce anything of demonstrable value, the development team has no indication as to whether or not what they are doing is the right thing, or whether or not it works as designed!

Without creating any product increment, we cannot know if the architecture we’ve spent time to design will support the features we need to build, whether it will scale, or whether it will actually inhibit our developers to the point that they will feel that they need to circumvent the architecture that was put in place.

Without a time-box, it will take longer to find out that the design is wrong, and if enough time was wasted – yes, wasted – in sprint zero, the efforts spent will have raised the cost of change to the point where undoing the damage will be too expensive, fixing the early decisions will be avoided, and the rest of the project will be spent finding ways to work around them, to the detriment of all involved.

And yet, the idea of a “Sprint Zero” has a more subtle flaw, one that is not intuitively obvious to anyone who read the guide, one that is indicative of a greater flaw of the entire organization, one that will have ripple effects into everything the organization does, as they attempt to enact an agile transformation:

Sprint Zero Robs You of a Learning Experience!

Many teams new to Scrum, or attempting an agile transformation, and even more than a few consultants will suggest that a team – particularly if they are new to Scrum – ease into agile delivery, by allowing them to “just this once” not follow agile principles. Why do they suggest this? because developing something valuable from scratch, in a single sprint or less is difficult. They might fail.

And this is the flaw.

Yes! You might fail to deliver something of value in a sprint. So what?!? With sprint zero, you are guaranteed to fail to deliver something in a single sprint, because you are not even trying!

One of the core agile principles is to “fail fast!” This means that if you are going to fail – and you are – it is better to fail sooner rather than later. Doing so means that your failure will be smaller because you’ve had less time to affect your organization, and it means you have more time to fix it because there is more remaining time until your project’s target date.

So yes, you are likely to fail if you try to deliver something of value by the end of the first sprint, especially when starting on a green-field project. But why did you fail? Was it a lack of resources? Incomplete understanding? Insufficient automation? Lack of a certain skill-set? Licenses? Environments? Something else?

Knowing why you failed to deliver something – anything – of value in a single sprint can be vital, not only for the product you are building, but even for understanding the nuances of your organizational culture. Finding out why you failed may help your organization’s agile transformation! Without failing fast at delivering a potentially releasable product increment, you would not know what your organization has to do in order to adapt to an agile culture, and support your team’s efforts.

Summary

Successfully delivering valuable functionality in the first sprint or three can be difficult, and for some, simply impossible. But the lessons learned from the attempt are invaluable! Taking an early hit, failing in the short term is unimportant if it improves the chance of success in the long run.

Moreover, failing can teach you valuable lessons, and if you learn from them and adapt accordingly, you will become more agile, and ultimately have a better chance at successfully delivering valuable software.

Learn from your mistakes. Adopt a Growth Mindset.

“The only real mistake is the one from which we learn nothing.”

- Henry Ford