Why using Sprint 0 is a cardinal sin for all Scrum Masters
You may think ‘cardinal sin’ is a strong word to use to talk about Scrum Masters that start their teams with Sprint 0. I don’t think so. I believe it is appropriate for the offense.
A Scrum Master using Sprint 0 is just as strange as an astronaut believing the world is flat. Scrum Masters should know better!
Unfortunately there still are many Scrum Masters who start their new teams with Sprint 0. In this article I will try to persuade you there is no convincing reason to use Sprint 0.
So let’s start by figuring out why Scrum Masters introduce the concept of Sprint 0 to their team.
What is Sprint 0?
There is no official definition of Sprint 0, as it is not part of Scrum. I would define Sprint 0 as follows:
Sprint 0 is a preparation Sprint you need to do before you can start doing real Sprints.
Sprint 0 is a Sprint with training wheels: a preparation for the real thing. Sprint 0 signals stakeholders not expect results until we really start. Please be patient for now.
During Sprint 0, Scrum Teams suddenly enter meeting rooms talking about team values, vision, building stuff with Lego and other cool things. Sometimes they make UX designs, mock-ups or technical designs. No pressure to deliver any code. Please wait as Sprint 0 will set us up for success in later Sprints!
I will now try to explain why this line of reasoning is wrong. Sprint 0 conflicts with Scrum on many different levels.
Sprint 0 conflicts with the core of Scrum
Imagine you would strip Scrum of everything to reach the core of what Scrum is about. You would remove all the roles, events, artifacts and rules of Scrum to reduce it to its absolute essence.
Scrum boiled down to a single sentence for a software development context would be:
Deliver a working product every Sprint
Imagine you perform all the roles, events, artifacts and rules, yet you don’t deliver a working product at the end of the Sprint. This means you are not doing Scrum. What you are doing is Cargo Cult Scrum. It appears like Scrum, but lacks the most important thing: a potentially releasable product increment.
This is why Sprint 0 conflicts with the core of Scrum. Each Sprint you should try to deliver a working product. It is okay to fail and learn from it. But it isn’t okay to set a goal to not deliver working software from the outset.
With Sprint 0 you’re starting your new team off on the wrong foot. It teaches them it is okay to have a Sprint where you do not deliver anything that works. This opens the door for all kinds of other anti-patterns, like hardening Sprints and abusing Spikes to create a mini-waterfall process in Scrum.
Sprint 0 clashes with the Empiricism of Scrum
The foundation of Scrum is empiricism. Empiricism asserts that knowledge comes from experience and you should make decisions based on what is known. By doing you will learn more. You may use this learning to do better than you did before.
By starting with Sprint 0, you have no product increment to inspect at the end of the Sprint. Therefore, your team will not run into the challenges involved with doing a real Sprint.
Sprint 0 results in reduced transparency: you will not encounter the real obstacles involved with doing Scrum. This leads to worse inspection and less adaptation.
You should do hard work and figure out what needs to be done to deliver value from the outset. By doing this you will be and running with Scrum in less time. It will also mean you will discover problems and risks earlier, which you can then tackle sooner.
Sprint 0 is incompatible with the Scrum values
The Scrum values are important to make Scrum work, as written in the Scrum Guide:
“When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.”
Sprint 0 conflicts with the Scrum values of Courage and Commitment.
Your team should have the courage to work on hard problems. Your first Sprint will be hard. You should start your first Sprint by creating an environment where it is safe to fail. You should not start a Sprint 0 to lower the bar by making it impossible to fail.
Your team should be committed to the team and the goals of the team. With Sprint 0 no one expects anything to come out of the Sprint, with less commitment from the team as a result.
So how should you start your first Sprint?
Everybody expecting the first sprint to be big success will be disappointed most of the time. Creating an environment where you team has the permission to suck is essential. You do not need Sprint 0 to manage these expectations. You do need to manage your stakeholders before you start.
Your first Sprint should be as any other Sprint. In Sprint Planning the Scrum Team crafts a Sprint Goal together. It can be as big or small as the team wants it to be. The Sprint Goal should guide the team towards what to deliver in a working product at the end of the Sprint.
When you need more time to prepare for next Sprint, then this can be achieved by setting a less ambitious Sprint Goal. A smaller Sprint Goal will create more space for other activities. However do not make the Sprint Goal too small as otherwise the preparation work may conflict with the Scrum value of Focus.
The Product Backlog and Sprint Backlog do not need to be fully formed and clear when you start your first Sprint. I even have started a first Sprint with just a Sprint Goal and a couple of Sprint Backlog items. It is okay to figure out things as you go along and update details in the Sprint or Product Backlog along the way. Is there a higher risk of failure? Yes. Is this a problem? No. It should be okay to fail because you managed these expectations.
Ditch Sprint 0 to set your team up for success in subsequent Sprints
Do not use sprint 0 as there is nothing to gain by introducing the concept.
In fact, sprint 0 sets your team up to fail for the following reasons:
- It teaches your Scrum Team it is okay to not aim for delivering a working product. It conflicts with the core of Scrum. This opens the door for all kinds of other anti-patterns, like hardening Sprints and abusing Spikes to create a mini-waterfall process in Scrum.
- The sooner you actually try to deliver something, the sooner you will discover the challenges that are involved in doing Scrum. The whole point of Scrum is that investigation and preparation is no substitute for real world experience. Before starting there just is not enough information available to prepare and investigate exactly what needs to happen. With a real Sprint you will learn quicker and discover the real problems involved with delivering a working product.
- Sprint 0 conflicts with the Scrum values of Courage and Commitment. By starting a real Sprint, the Scrum Team can discover and embrace the Scrum values sooner which are necessary for Scrum to be a success.
The alternative to Sprint 0 is to do a regular Sprint and start with the Sprint Goal. It is okay not to know all details and figure it out as you go along. Manage the expectations that your first Sprint will fail with stakeholders and give your team the permission to suck.
The first Sprint from a Scrum perspective is always the hardest. Give your team the courage to aim for a Sprint Goal. Let them discover why Scrum is easy to learn but hard to master. Knowledge about Scrum is gained by experience. Sprint 0 will never be a substitute for rolling up your sleeves and trying to deliver something.
