You need to enable JavaScript in order to use the AI chatbot tool powered by ChatBot

What is Sprint Zero?

What is sprint zero?

Welcome to part 17 in our agile coach interview questions series where John McFadyen answers common questions asked of agile coaches and scrum masters in interviews and client engagements.

In truth, sprint zero is a term made up by people who have adapted the scrum framework to suit their own purpose or need. It isn’t mentioned anywhere in the scrum guide nor is it a recommended practice or best practice for product development teams.

Pre-Sprint Preparation

As I have heard from other agile coaches and scrum masters, sprint zero is really about a sprint which is dedicated to helping the team get ready for scrum. Something they do to actively prepare for their first sprint that involves product development or the product development sprint in the cycle that they observe.

In other words, planning for future sprint planning.

This would include things like:

  • Making sure that they have a backlog
  • Making sure that the technology is in place
  • Making sure that the product owner is on top of their backlog
  • Making sure that the developers have everything they need to do the job

And so forth.

In my experience, organizations and teams who aren’t great at getting organized or getting things done tend to be the ones that invest in a sprint zero, either once off or on a regular basis.

What I would recommend instead of a sprint zero.

The purpose of scrum is to bring a small group of skilled, talented people together to create a working product or feature within a short period of time known as a sprint.

That is the only sprint you should be committed to.

The sprint that delivers a valuable product increment for a customer or end-user.

If you are stuck in the logistics of something, say the need to set up the servers for example, great, put that on the backlog to be included in sprint planning. Whatever preparatory work you need to do or ensure gets done, include it in the sprint backlog as a priority to deliver so that the team are building momentum and delivering valuable increments in each sprint cycle.

Some people might object that it doesn’t form part of the user stories but in my opinion, scrum doesn’t care about user stories or protocol. It cares about initiating the creation of a product or the solving of a problem and finishing that item within a short space of time.

Your own team may be the customer or end user for that item on the backlog. It doesn’t matter. Don’t get caught up in dogma or attempt to combine waterfall project management with Scrum, just get the item into the backlog and help the team figure out how to get it done.

If the item is intrinsic to building or delivering a product, then it counts as a backlog item. Simple.

Sprint backlog deficiency

A common reason for a sprint zero is that the team or leadership team don’t feel like there are enough items on the backlog to get going.

I would counter that by asking just how many items you need in a backlog to get going?

Scrum is built on the foundation of empiricism. The three pillars that make up Empirical Process Control are transparency, inspection, and adaptation.

In other words, you form a hypothesis and then design an experiment to prove or disprove that hypothesis. In essence, you are discovering what is right and what doesn’t serve you, and so the process of doing is incredibly important because the data informs what you should do next.

Don’t get too caught up in having volumes of items on the backlog before you begin.

Select enough work for the sprint you have determined and get cracking on that. You will learn or discover what needs doing from there and you will have feedback from customers and product stakeholders in the review that will further inform what needs to go onto the backlog.

Just get started. Just start building. Just start solving problems.

The rest will fall into place.

How long should the sprint be?

It is up to the scrum team. It could be up to a month long and it could be as short as a week. On average, organizations tend to go with a 2-week sprint or a 4-week sprint, but you could decide based on your backlog items what sprint cycle works best for you.

As stated earlier, scrum is built on the pillars of transparency, inspection and adaptation.

If you find that a week is too short to deliver a valuable product increment, great, have a sprint retrospective and discuss your options as a team. You may have a hypothesis that a 3-week sprint will better serve the team and you can then make the decision to extend the sprint cycle.

Inspect. Learn. Adapt.

Start sooner than you are ready.

In my product owner classes, I always recommend that a scrum team and product owner get started sooner than they are ready because you are not going to get better feedback, from anywhere, than you will from giving a product to a customer or end-user for feedback.

Just build the thing, host the sprint review, and get the feedback from the only opinions that matter.

The people who are buying the product and the people who are using the product.

They may love what you have built and provide you with insights into additional features they would love to see, or they will hate it, but tell you exactly what they hate about it and why it doesn’t solve their problem or meet their need.

Either way you have valuable feedback to inform the product backlog and help the team make better decisions in the next sprint planning event and sprint.

The sooner you start this process, the sooner you start this virtuous cycle of inspect, learn, and adapt.

Sprint Zero Summary

So, in closing, you don’t need a sprint zero and if you are in an interview scenario, I would recommend that you advise the organization to consider the information and insights I have offered above.

Encourage them to just get cracking and let them know that you are the perfect agile coach or scrum master to coach them through that process of discovery, learning and adaptation.

About John McFadyen

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster

author avatar
John McFadyen Managing Partner
John McFadyen is an Executive and Enterprise Agile Coach with proven experience working on some of the UK and Europe’s largest, most complex Agile Transformations. As a Certified Scrum Trainer, John brings a wealth of experience as an Agile coach, Agile practitioner and software developer into each of the four core courses he provides. The war stories, the insights into successful Agile transformations and everything he has learned from coaching high-performance Agile teams combine to provide course delegates with a unique, compelling training experience that transforms as much as it empowers.

Like this post? Share with friends & colleagues using the share buttons below.


Related Blog Posts

Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen