Understanding Sprint Zero in Scrum
Having a Sprint Zero in your project can be a controversial thing. Not formally recognized as a separate Sprint or a Sprint type, it's sometimes rejected by some Scrum advocates. Let's dive deeper into it and see why it's so controversial, and what benefits it can bring when executed properly.
If you are reading this post, chances are you are already quite familiar with Scrum. If not, it is an Agile framework focused on delivering the value incrementally in time-boxed iterations. Scrum’s main advantages are that it helps to maximize the effective use of time and money, adapt quickly to the changing market conditions, and that is working well with fast-paced projects. The benefits of Scrum, however, are only some of the topics I wanted to bring up in this post.
Instead, I want to focus on one controversial element often cut out because of either time or financial constraints, or even disregarded completely by some Agile specialists as not belonging in Scrum at all - namely, Sprint Zero.
Sprint Zero can be defined as a preparatory phase before or shortly after the start of the project. Its main aim is to set up further cooperation as smoothly as possible by bringing the team together and ensuring all the tools and accesses are provided. Sometimes it can also be used to create an initial Backlog, User Stories, or project artifacts, such as a Definition of Done, a Definition of Ready, or a Working Agreement.
Well executed, it can result in a smooth start for a project, a motivated team, and even a rough estimation of the project’s timeline.
With all the benefits a Sprint Zero can bring, why can it be, in fact, controversial? To answer that you need to remember one of the core rules of Sprints in Scrum. Each of them should result in something that is ‘potentially shippable’ - in light of that, calling this preparatory phase of a project cannot really be called a ‘Sprint’.
From the client’s perspective, it can also be seen as an unnecessary cost - you are, after all, burning the team’s time, and there is a possibility that you will have little sellable items to show for it.
It is not the only problem, though. If you are introducing a new type of Sprint to your Scrum framework, why stop there? Some people argue that with adding a Sprint Zero, there is nothing to stop you from adding other types of Sprints while you’re at it - a Design Sprint, a Spike Sprint, a Handover Sprint, you name it (literally).
As a result, with projects adhering strictly to Scrum rules, you will most likely see elements of Sprint Zero incorporated into activities before the project start, or into the first ‘real’ Sprint.
As you can see, there are certainly some controversies involved in starting your project with a Sprint Zero. From my perspective, it is a valuable part of the project and a time well spent. In order to make that decision for yourself, let me provide you with a couple more facts, so it is an informed one.
To fully utilize the time spent on a Sprint Zero and its benefits, there are several elements that I think should happen. They are as follows:
- Project kickoff - if it didn’t happen already. Take your time to prepare yourself and the team to research the client and the market they are operating in. Ask any questions you might have and align on the expectations.
- Team alignment - depending on the size of your organization, the team gathered for the project might not have had the chance to work together. Use that time to allow them to get to know each other, their work style, assign roles and responsibilities. Allow them to express their expectations and write them down in a Working Agreement.
- Product understanding - make sure your, your team’s, and the client’s vision of the project are aligned. Do not be afraid to ask questions and clarify anything you feel is unclear.
- Future work setup - Based on the info you get, start preparing the initial backlog and plan the first Sprint of work. Make sure to choose the right infrastructure, tools, and communication channels. Agree on a Definition of Done and Ready, and create any other necessary artifacts.
As you can see, even though it's an initial phase, it is by no means an idle one. Gathering and setting up the team, aligning the vision with the client, preparing artifacts, and the Backlog - it all takes time. You might ask yourself - why bother, or, more precisely, why bother now and not in Sprint One?
I believe that successfully completing the activities in Sprint Zero will make your life and your work far easier in Sprint One for several reasons. With the clarity and vision aligned with the client, you can start focusing on what really matters right from the get-go. Setting up the work will mean you also have the tools to execute that vision with a team that is already familiar with what needs to be done and in sync with how it should be achieved.
It might even allow you to plan better for any potential pitfalls and manage the risk from the very beginning, by identifying challenges and addressing them early.
Having a Sprint Zero in your project can be a controversial thing. Not formally recognized as a separate Sprint or a Sprint type, it’s sometimes rejected by some Scrum advocates. Clients might not want to spend time, seeing little ‘shippable’ benefits for their money.
In my opinion, though, by allowing you and your team a little breathing space and focusing on the proper understanding of what needs to be done and how to go about it, you are setting yourself up for success - and that is an effort worth making.
Empower your vision, partner with us today
ㅤ
Trusted by: