Does a Scrum Project Need Sprint 0?

One of the most debatable topics in Agile especially Scrum is whether a team can actually deliver something potentially shippable in the first Iteration or Sprint. Some folks suggest a Sprint 0 while some oppose it as they feel it is against scrum principles.

The purpose of this article is to help you understand whether a Sprint 0 really makes sense or not…

What is Sprint 0?

Sprint 0 or Iteration 0 is technically the first iteration of an agile project but it is more used for getting the preparatory work done rather than actual development. It is like a feeder sprint for the scrum team and product owner to work together to understand the backlog, discuss the relative priorities, estimate the top priority items and get ready to work on the most important stories in the first official development sprint of the project.

Do we really need a Sprint 0?

Technically No.

Lets assume you are the scrum master and are starting a new scrum product development project. You are meeting the product owner and the scrum team on a Monday morning which happens to be Day 1 of your Sprint 1.

You and the team are probably new and have little to no idea about the product you are going to building. The product owner is probably still refining his priorities and the first few days of the sprint will go in the team getting to know each other. Unless you do a 4 week sprint, by the team they identify the top priority stories, estimate and break it down into tasks we are probably 50% or more into the sprint and will not have enough time to do any worthwhile development that can be shipped by the end of the sprint. Even in a 4 week sprint, it is highly debatable as to how much actual development the team would be able to do after they get the basics sorted out.

According to Scrum, a Sprint is time boxed and you have to mark the sprint as completed by the end of the sprint. So, chances are high that you will have many incomplete stories by the end of your first sprint.

By adding a Sprint 0, I took the delivery pressure off the team and spent the first few days building the team and working collaboratively on the backlog to understand what the team is going to build. At the end of sprint 0, we have a decent shape backlog and the team has a few user stories that they can start work when Sprint 1 starts.

How long would a Sprint 0 be?

Ideally a team would need anywhere between 1-2 weeks to get familiar with each other and get the preliminary backlog of work ready. So, I would suggest you plan for a 1 week sprint 0 if your usual sprints are 1 or 2 weeks in length and a 2 week sprint 0 if your usual sprints are 3 or 4 weeks in length.

Is adding a Sprint 0 to the release schedule really scrum or agile?

Going by technical definition of the methodology No, I don’t think so. Sprint 0 is more like a planning period where the team work out the details of how they can work together in the coming weeks/months. Since, scrum doesn’t explicitly recommend a planning phase for a project and expects us to cover everything within the sprint, we cannot say that our project is doing scrum if we add a sprint 0.

At the same time, Agile is an adaptive mindset and approach where the team is free to tweak their processes to enhance their output. By adding a sprint 0 the team is basically improving the efficiency and delivery capabilities of sprints 1 and beyond so, I would say that even if we add a sprint 0, we will still be doing agile if we follow the other core principles that agile was built on – customer focus, regular delivery of value, adapting to changes and continuous improvement.

Real life scenario:

In real life agile projects, you can also find teams that use a stabilization or regression sprint toward the end of the major release where the team will make sure all bugs are fixed, pre-existing functionality that was delivered as part of the last major release are working fine and the product meets the quality standards set forth by the organization.

Again scrum & agile purists will argue that adding such an iteration is against the scrum methodology.

Yes, I cannot deny that. But, practical usability and fitness for purpose always trumps idealistic processes. If I am delivering a major product version to a customer, he would be more concerned about my project team delivering a quality product rather than following scrum perfectly. So, going by customer focus as our teams main goal, we are using one sprint to make sure the product is fit for use and delivering the same to the customer and I would still say that my team followed agile methodology because we did follow all the agile principles.

What are your thoughts on sprint 0 and a stabilization testing sprint? Sound off in the comments section…

Does a Scrum Project Need Iteration 0?

We all know that scrum projects work in Sprints or Iterations and continue to deliver incremental features on the product at the end of each Iteration. In real life, how many of us have worked on a sprint project where the team was actually able to deliver something shippable at the end of the 1^st Iteration? The answer to this question would be very small for a very simple reason. During the first sprint, there are too many unknowns, the backlog isn’t ready or the team isn’t assembled yet and so on.

So, if you want the team to deliver from Iteration 1, what should we do?

The answer is – Iteration 0…

What is Iteration 0? 

If you are someone who has worked on Agile Projects before you already know that we need to assemble the team, get the preliminary product backlog ready, establish team roles and responsibilities and complete many other activities before actual development work can start. Right?

Considering all this, it is inevitable that the first sprint is usually spent finding our more information and doing all of the aforementioned activities which means the iterations output of shippable product features is mostly negligible or non-existent. When we publish the Sprint or Iteration Plan for my projects, I always start with Iteration 0 where we get all the prerequisites ready and then the team can start delivering from Iteration 1.

Is this Right or Is this Wrong?

According to Scrum principles, every Iteration should produce an increment of product features that can be shipped to the customer. If we take this principle as a hard reference, we shouldn't have a Iteration 0. Instead, we should be able to do all this in the first sprint and also deliver an increment which is very unlikely.

At the same time, Scrum advocates the inspect and adapt methodology which gives the scrum team enough freedom to inspect on their processes and adapt/make changes as required to make their functioning better. So, if we apply this principle then doing an Iteration 0 to get things ready is right.

Unfortunately, I cant give you a concrete Right or Wrong answer to your question. It is up to you as the Scrum Master to discuss with your team and if you think the goal is to start delivering incremental features from iteration 1, then it makes sense to have an Iteration 0 to make things easier for the team.

Real life Trivia:

Sometimes, teams may not have the luxury of a 2 or 3 week break between Major Product Version releases and usually get started on Iteration 1 of the next major release right away. In such situations having an Iteration 0 is just not feasible. If I am faced with such a situation, I usually work with the product owner and maybe one of the senior scrum team members to get the prerequisites going 2-3 weeks prior to the current release deadline so that when the next release development iterations start, my team has enough info to start delivering…

What do you think about this idea of an Iteration 0?