There are a lot of opinions on whether sprint 0 should exist or not in a Scrum project. I personally think that what is confusing about it is the fact that the term is misused for what we really want to do. That is, we call it sprint 0 but most of us don’t pursue having a deliverable at the end of the sprint. What we really want is to prepare what is necessary for the environment we will work in.
There are multiple ways sprint 0 is put into practice. For some it’s a timeboxed activity where they put together the team, others are configuring their CI/CD pipelines, or UAT environments. Some are trying to get people on the same page about how they will work together and understand the product vision.
Scrum doesn’t recognize sprint 0 as being part of the framework. That happens because based on the Scrum Guide, at the end of each sprint there has to be something delivered. Whereas sprint 0, won’t deliver any working functionality. And if there is something that will be delivered, why not call it sprint 1? I’m not using sprint 0 with my teams but what’s certain, is that preparation time is needed before starting sprint 1.
How to prepare before starting sprint 1
Before going into a sprint, I generally have a couple of activities that I do with my teams. Stakeholders are present too. I don’t name it like that because it might generate some misunderstandings later on.
We simply take 2 weeks to prepare. Meetings for clarifications with stakeholders take place every day for at least half an hour and for the rest of the day the Development Team has multiple syncs to setup the environments and understand the codebase.
Two weeks are usually enough to prepare for the first sprint and make some estimates, even if not accurate ones. So make sure you timebox it and you don’t spend too much time in this phase.
Otherwise, you’ll fall into the trap of planning everything before starting to really work on those items and in the end, you’ll move away from what Scrum stands for.
Have a kick-off meeting. This will allow your team to get to know each other and understand what is their role. You can include here the key stakeholders as well. This is the time where timelines can be brought into the discussion, the product vision, and other high-level business and technical matters
Have the team do high-level research. They can look into API documentation, study the product, maybe have a Sandbox environment where they can make some tests. You can even identify some risks in this stage. So make sure the team gets all the data they need at that point for them to start sprint 1.
It’s very important to find your definition of “Done”. Everyone must have the same understanding of what “Done” means. Make sure you share this with everyone involved in the project. You have to enter sprint 1 with everyone having the same expectations.
Refine the backlog. Take some of the most important stories in the backlog and refine them. These are the stories that are defining the product and without which it’s impossible to move on. Split them into smaller chunks and estimate them. Order them in the backlog and start working on them in your first sprint.
Start setting up the environment you will work in. The team can start setting up the tools they will work with, servers, communication channels, and so on.
Now that all of these are clear, you have what you need to enter the sprint with just enough information.
Why there’s no mention of sprint 0 in the Scrum Guide?
According to the Scrum Guide, at the end of every sprint, the team has to deliver something that is functional, something that brings value to the customer.
If you need to have this type of preparation with your team, and if you intend to refer to it as sprint 0, I suggest you make very clear what will happen and how is it different from sprint 1. Otherwise, it can create confusion especially among teams that haven’t worked yet with the Scrum framework.
As part of the onboarding process, the team may take a PBI to work on just to get familiar with the process and code, but that PBI might not get done at the end of sprint 0 because there’s a lot for a new team in a new project to learn.
So just take the time to understand what you need as a team, get the proper amount of training and then start your sprint 1, when the team feels comfortable to commit to delivering some small items.
Things to be aware of
Spend just enough time in this phase. Don’t make it last for too long, you don’t want to end up doing Scrumfall.
Try not to call it sprint 0. You can try something like Pre Delivery Preparation, or Clarification Meetings, or anything else that suggests that you are preparing the minimum necessary so that you can start your first sprint prepared. A sprint is an event at the end of which working functionality will be delivered. And if you call it sprint 0, the Product Owner might expect to see an increment shipped.
Don’t misuse sprint 0 to describe the planning that occurs before sprint 1. There is a pre-planning phase that has a purpose assembling the team, clarify contract terms, clarify the product vision, and other business-related matters to figure out.
For teams that are new-formed and didn’t work together before, this prep time is a good opportunity to get to know each other and understand how they will work together. But it works for teams that already have some background together too. Due to lack of preparation, sprint 1 might not be as effective.
It’s true that in some cases there is no need for this kind of preparation. Say that you already have a product and your projects consist only of enhancements or adding extra functionality. The core is already established, the roles are well defined and all you need in these cases is to present the new features that you want to add to the product. And make sure the team understands the goal.
Have you worked with sprint 0? How do you organize the preparation phase? Leave a comment down below, I’m curious what your approach is.
