Get certified - Transform your world of work today


What Is Sprint Zero?

4 September 2013

Anurag Prakash
Blue Cross Blue Shield

Motivation for Sprint Zero in a software project

The idea of Sprint Zero, like a lot of other things, has been used and abused. Assuming two-week sprints, and assuming that Sprint Zero is four weeks, let's examine some of what is claimed as Sprint Zero activity.
Claim1: The team needs to be assembled in Sprint Zero. If team members have not been hired yet, there is no real way to get people in three weeks. It usually takes longer than three weeks to get resumes, develop a short list, conduct interviews, select, and bring someone onboard. If you do not have a team, you don't have a sprint. What's more, in many cases the new Scrum team may simply be assembled from within the organization, in which case there is not much work being done to justify a sprint.
Claim2: Organization and logistics need to be set up in Sprint Zero. I have not heard this view very many times, but some people have said this to me during conversations. Again, chairs, desks, workstations, SharePoint sites, etc., are important items, but these are really supporting activities to the real job of producing a feature or a product. These activities can happen any time or could be happening continuously in background. A just-in-time approach will work just fine. For example, we can source monitors, software installs, etc., as people come on board.
Claim3: Consider planning, product backlog setup, and design. This is my favorite, as it clearly indicates two things:
  1. Someone is finding it hard to move away from Waterfall.
  2. The organization is finding it difficult to give up control and empower the team.
Introducing a long Sprint Zero at the start and a long validation at the end helps keep the love for Waterfall alive. In addition, it hinders the effectiveness of Scrum.


What Sprint Zero frequently ends up being

If Waterfall works for you, then by all means, you should use Waterfall. This article focuses on teams that follow the Scrum rituals but keep the Waterfall soul.

Scrum believes that every sprint should deliver potentially usable value. None of the above Sprint Zero items produce any value for the customer. They cannot be demoed. To be effective at Scrum, we need to change our design thinking. In addition, there is no reason to be setting up logistics in Sprint Zero. In most organizations, there are separate groups that handle these things, and so the setup tasks can be assigned to someone to be done in parallel. Setting up logistics is not a story, it's a support task. A just-in-time completion of support task works fine, even as advance completion may be welcome.

Considering planning, product backlog setup, and design in Sprint Zero is a proxy for "big design up front" (BDF). In Agile we try to stay away from that. Often, an associated symptom will be a very hierarchical organization, thus preventing the Scrum team from being really empowered.
  • Personnel who are most active in Sprint Zero may be different from those most active in other sprints.
  • The Sprint Zero leaders will "guide" the team through sprints but may not feel bound by the time and other constraints that the rest of the team has.
  • This creates a two-level organization instead of the flat one that Scrum promotes. A two-level organization tends to follow a task-assignment and status-reporting culture, instead of a mind-set of ownership and delivering value.

What Sprint Zero should be

Before we define Sprint Zero, let me say that the long system test phase before the release can actually be an automated regression test. Each sprint can create automated test for the features it implements and add that to the regression. The need for automated tests is much discussed in Scrum and Agile literature, so we will skip it here for now.
Now for a working definition of Sprint Zero:
  1. Sprint Zero should be used to create the basic skeleton and plumbing for the project so that future sprints can be truly add incremental value in an efficient way. It may involve some research spikes.
  2. Minimal design up front is done in Sprint Zero so that emergent design is possible in future sprints. This includes putting together a flexible enough framework so that refactoring is easy.
  3. For minimal design up front, the team picks up a very few critical stories and develops them to completion. Since these are the first few stories, delivering them includes putting the skeleton/framework in place, but even Sprint Zero delivers value.
Note: The velocity of Sprint Zero may be very low compared to that of other sprints.
Remember also that the product backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be begun during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero's start, enough to help us demo at least one working feature.

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: 3.5 (15 ratings)


Phillip Stiby, CSM, 9/4/2013 5:52:33 AM
Sprint Zero, don't remember reading that in the scrum guide. Anyway I thought Sprint zero was a developer principle because all lists start at zero.. ok jokes aside...

When I was presented with a greenfield project with an established development team we didn't have a "sprint zero" but we did have 2 days prep and planning allowing the team to read through the documentation, ask questions and the product owner to put a few of the highest priority stories onto the product back log and plan the first sprint.

The team decided on a 4 week sprint, because the team knew they could not deliver any value in 2 weeks due to a number of starting impediments.

Whilst the scrum master worked on the impediments the development team starting producing working code, performing spikes to investigate risk areas. Likewise testers had time to go through the prepared documentation to build up test plans, report defects within the documentation and there own spikes.

This first sprint also gave the product owner with sufficient time to build up a more complete product backlog, perform a couple of sessions with the team to size up the items and breakdown where necessary.

So after the first sprint was completed the team delivered its first increment, for this project was a big success as the demo was taken to the client the very next day (impacting the team as the development servers were locked down for several days). The product owner had a backlog with initial sizing, and because of the established team with an existing velocity the Project Management team had a good idea what could be delivered what the costs were and weather the project would be delivered on time.
Zach Bonaker, CSP,CSM,CSPO, 9/4/2013 9:39:41 AM
The guts of your article, in my opinion, are spot on. I've observed plenty of BDF in "Sprint 0"... especially when the two-week "design sprint" turns into another two-week "design sprint", etc.

However, my preference is to avoid using all of these "just-can't-let-go-of-waterfall" names... "Sprint 0", "Zero Feature Release sprint" (ZFR... or "ziffer").

Instead, call it what it is. The first sprint. The ever popular "Sprint 1". Do a day or two of backlog grooming to get the highest value PBI understood or broken down, then get to work. Produce something - even if it's very small compared to expected velocity, demo it, and begin the journey!
Anurag Prakash, CSM, 9/9/2013 5:14:34 PM
One of the major issues in getting to true Agile is the reluctance to be open to new possibilities. Few folks, that I have met believed that Emergent design was possible.

In organizations where roles have become well defined, its not easy to imagine something different. So Sprint0, Hardening Sprint, Preplanning stage etc. are introduced as a bridge, which tends to limit Agile execution to the developers. Everything else in the environment continues to be some mish-mash of Agile and something else.
G. Manto, CSP,CSM,CSPO, 9/17/2013 5:00:17 PM
I've also found that Sprint0 is both a useful bridge to ease folks into Scrum as well as common wrapper for folks who see value in BDF. For both, if the outcome is a workable Product Backlog which is groomed/delivered Sprintly, then I think that is good progress.

If your intention is to change the organization in one project, then Sprint0 may be viewed as a failure in achieving that outcome. If your intention is to further anchor (or improve) a Scrum common practice, then Sprint0 may be viewed as successful in achieving that outcome.

So, using and calling a Sprint "Sprint0" is similar to choosing to either use Story Pointing or Shirt Sizes. If one fits better with your team/org and can help you achieve the desired outcome, then go for it.
Anurag Prakash, CSM, 9/20/2013 2:42:06 PM

Good points. Sprint0 is definitely useful during transition and as a wrapper for BDF. However after that, subsequent projects should complete at least one story in Sprint0.

If there is no progress away from BDF after the first project, then the org. is probably putting more emphasis on Scrum "Rituals", and not on "Engineering Methods" that enable Agility.
David Geissler, CSM,CSPO, 4/15/2014 1:33:31 PM
You say that Sprint Zero is 4 week sprint for a 2-week sprint cycle. In my experience the Sprint Zero should be at maximum the size of the sprint cycle (so 2-wk sprints = 2-wk Sprint Zero). This gets the team prepared for the continuing cycle and generates enough foundation work for them to be successful. Depending on how prepared the company is to support teams, Sprint Zero should not take a great deal of time but can take a great deal of effort. This is where the Scrum Master earns his/her stripes.
Joseph Collins, CSP,CSM,CSPO, 7/24/2014 11:09:29 PM
I work within a split site, government operated, contractor supported organization. As a senior Scrum Master, I have directed the team Scrum Master to include a sprint 0 due to organizational issues encountered over the past two sprints. The team is new, their lack of knowledge makes them overly reliant on outside knowledge holders. The system is very complex and requires signification research to understand our poorly documented code base and the impact of the changes they are about to make. The team has failed to meet the definition of done for any story for two sprints now due to these issues. In an attempt to do the three items suggested in the working definition above as well as conduct risk assessment (new concept for this team) and coordinate with the PO in the hopes that he will provide a proper product backlog, we are going to spend the next 2 weeks in a sprint 0. It is not my intention to hold on to any waterfall practice nor is it my desire for them to do big design up front. If I find out that is what they are doing, I will be highly disappointed. I hope this two weeks pays dividends over the next 8-10 sprints of this project.
SHAILESH SONI, CSM, 11/2/2015 7:39:52 AM
its really difficult to get people and mgmt out from waterfall model, Management pushes for adopting Agile but do not initiate talks with client product owner to take the ownership. even though all the documents / tracking in place, SM is expected to act as Project Manager and push the team and send status report and is responsible for product failure.. ;)

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