Get certified - Transform your world of work today


Why Have Sprint Zero?

2 September 2016

Sujatha Tokala
Innominds Software Pvt Ltd

I realize that the concept of a Sprint Zero is a controversial one. And in my initial days of Agile, I was surprised by the importance given to it where I worked. I thought that we would have knowledge-transfer sessions while we did the work, so why did we need to have a separate sprint? But later I realized the importance of Sprint Zero at the organization in which I work. I will not claim that all teams need it, but here is why it is useful for us.

Sprint Zero action items apply to the entire release. We can call it the Initial Sprint, Iteration Zero, or Inception Sprint. In my experience, Sprint Zero is a timebox of one week only.

The team reviews the overall release items and what work must be completed in each sprint. While reviewing each sprint item, the team identifies the areas for which they do not know the requirements, whether they are hardware, architecture, software, or technical.

After the team has glanced at the prioritized epics/features from the product backlog, it has to note the epics and prepare to take the grooming sessions from the product owner. The team must understand the environment and code required for the product backlog features, regardless of whether the code is simple or complex.

The reason for introducing Sprint Zero is that you don't want to unnecessarily extend time to understand the grooming sessions or conduct knowledge-transfer sessions from Sprint 1 onward. So we take one week to prepare the team before starting the sprint backlogs.

Thanks to Agile, we are given the opportunity to learn in a short time. The team will groom in a calm way, with no undue pressure.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.3 (3 ratings)


Tim Baffa, CSM, 9/2/2016 9:15:49 AM
It is counter-productive to take 1 week to "line everything up" before a team begins working with a Product Owner and accepting offered work from their backlog. Nothing is being produced in that time period.

It would be far better to simply begin the first sprint with an identified Sprint Goal and a lighter load of stories, in consideration of architectural or design discussions needed, as well as time to groom stories with the Product Owner for future sprints.

This is symptomatic of traditional project management, where the mindset is not to start any work until we've developed an extensive plan for reaching the goal. There is simply little "agility" supported with that approach. And if any of the initial "assumptions" regarding hardware, software, or architecture are incorrect or need to change, this "Sprint Zero" is time that is simply wasted.

In addition, there should not be any discussions around planning future sprints around potential releases. This is again symptomatic of traditional project-plan thinking. The team should stay focused on the current sprint, and begin thinking only of the next 2-3 sprints. Release management is the sole responsibility of the Product Owner, to adjust as needed based on business priority and feedback from completed sprints.

Any team-related effort to discuss items that project more than 2-3 sprints into the future is again a wasted effort, especially if changing business priorities or competitive pressures bring about a reshuffling of the Product Backlog.
Aditya Kumar, CSM, 9/6/2016 12:54:43 PM
Hi Tim, In a way I agree with your view point however sometime I struggle a bit in initial sprint of a product/project where we typically want to decide and finalize the base/best fit technology and architecture and there is no tangible outcome to showcase in sprint review. Having said this, I still think we should not have separate sprint 0 just to finalize or understand the requirement better. It is actually a symptomatic of traditional waterfall model thinking.
Phillip Stiby, CSM, 9/15/2016 8:30:23 AM
A sprint is to deliver an increment, if your not delivering an increment your not performing a sprint.

You are biding time to get a backlog together due to either procrastination, analysis paralysis. Sometimes your waiting for a design but that is something the team should be able to do if your following the scrum values.

You only need is an idea and a team and you can start your first sprint, remember Scrum is a process of continual improvement so better to start sooner than later to make things "perfect", but remember working software is better than perfect.
Sujatha Tokala, CSP,CSM, 12/22/2016 7:36:31 AM
Thanks for providing feedback on this article.

I like the idea of Scrum Sprints. During each sprint, team creates a potentially shippable product. To provide this result, Sprint zero must plays a key role in the Scrum methodology like high level application architecture, list of all prioritized features/stories with estimates, release plan that assigns each feature/story to an iteration/sprint.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up