Get certified - Transform your world of work today

Close

The Case Against Sprint Zero: How to Stop Stalling and Start Sprinting

Projects do not spring to life fully formed--that is, staffed and ready to be worked on. To address these pre-project tasks, many teams use something that they call "sprint zero." I understand where the idea comes from. Yet, I worry about it. Here's why.
 
3 Reasons to Drop Sprint Zero
First, though it might be hard to believe, the vast majority of projects can start instantly. I've heard all the claims for things that have to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero. Yet the reality is things like technical environments and an initial product backlog can be figured out during the first sprint--a good, old fashioned sprint number one--while also delivering at least some sort of potentially shippable product increment.
 
Second, having a sprint zero establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product? The requirement to deliver a potentially shippable product increment exists to help Scrum teams avoid analysis paralysis and to feel a sense a urgency to produce something within the sprint. Just the right amount of urgency can generate greater creativity. The rule also exists to help Scrum teams stay honest--it prevents them from claiming progress when none has been truly made.
 
Third, on the rare projects that do require pre-work, what I call the project before the project, that pre-work may take more than one iteration. After all, these must be large projects to truly require pre-work. In that case, we might need a sprint zero, sprint 0.5, sprint 0.75--where does it end?
 
But We're the Exception. What Do We Do?
So most projects don't require pre-work; that work should be done alongside the development work. But let's say you are working on one of those rare projects that requires a project before the project. How can you ensure the analysis doesn't end up bogging down and becoming more expensive than just starting the project in the first place?
 
Tip #1: Keep any "project before the project" lightweight. You can even use Scrum to manage the project before the project, working in teams with timeboxed iterations. At the end of each iteration, ask, can we start now, even if it's only on a small scale, and decide on the rest of this as we progress? Often you can find a way if you think creatively.
 
Tip #2: Finish frequently. Even a team that is only analyzing a potential system can break the work into small, finishable tasks. For example, suppose you are trying to decide whether to create a new hospital system, or what kind of hospital system to create. Rather than committing to "interview all the stakeholders," maybe the team could first decide to interview all the pharmacists about their basic requirements. Once that task is complete, they could interview all of the doctors. Or they could break the work into topical areas: talk to all stakeholders regarding their needs for the prescriptions part of the system. In this case, the team spends the sprint interviewing not just pharmacists but also some medical doctors, nurses, and so on. They don't talk to these stakeholders about anything but the prescriptions part of the system. They'll come back and talk to stakeholders about other functionality in successive interviews. For now, though, this team can be said to be done analyzing needs of all stakeholders involved with prescriptions.
 
I'll say it again: Most development projects do not need a project before they begin. Almost all of time, analysis work can be completed inside the iterations of the actual sprint. When you do need to do pre-project work, do it quickly, with urgency, and in small fiishable chunks.
 
Do you want one short tip each week from Mike to help you succeed with agile?

 

Article Rating

Current rating: 4.6 (13 ratings)
Comments
Anton Skornyakov
Absolutely! So far, I've always been able to define a "Hello world" story - as in the Alistair Cockburn's Elephant Carpattio exercise. Implementing this is always so much more revealing than any "preparation work".

But being comfortable with starting this way, you really need to trust that architectures, requirements, and designs will EMERGE. And many people haven't experienced this...
2/12/2017 3:09:07 PM

Ram Fadnavis
Hi Mike,

we are using sprint 0 for setting up infrastructures like servers, space, automated builds and backlog formation. This is helping us to start with user stories from sprint 1.
11/21/2016 1:15:35 AM

http://showboxapk.co/
Great
10/13/2016 2:14:31 AM

vereador
I was surfing net and fortunately came across this site and found very interesting stuff here. Its really fun to read. I enjoyed a lot. Thanks for sharing this wonderful information.
9/24/2016 7:12:13 AM

csr classics
Click here and unlock the locked resources for playing CSR game online.
9/24/2016 3:29:07 AM

Mike Cohn
Hi Sathya--
I think what you're doing is about the only really good use for a sprint zero.
9/9/2016 11:56:41 PM

Sathyanarayanan Srinivasan
HI Mike, Thanks for your insights. We usually use Sprint 0 to firm up the fixed price for an agile project which clients demand most often. All work done to firm this number determines the duration for Sprint 0. Is there a better approach to this? Kindly advise.

- Sathya
9/9/2016 4:36:03 AM

Mike Cohn
I agree, Denise, 100%. In my experience has been very rare that even in a first sprint a team cannot deliver *something*.
7/14/2016 9:33:54 PM

Denise Hill
Like you, I'm not a fan of sprint 0. I like producing some amount of potentially releasable software even on the first sprint. It may be that first sprint has more analysis in it and a tiny velocity, but we always find a way to produce at least some working software.
7/14/2016 4:07:53 PM

Mike Cohn
Thanks, Sharon.

And I agree--that sounds like a reasonable use of a sprint 0 to me.
12/5/2015 1:40:39 PM

Sharon Hearn
Great article Mike, as usual.

We did have a Sprint 0 when Scrum was first introduced at my company. It was meant as a "cleansing" of the old as we had several previous R&D managers in a short amount of time. The new R&D manager was a very big proponent of Agile/Scrum; this was a new concept to everyone at our company. He wanted to get team members and stakeholders on board with the concepts laid out in the Agile Manifesto and the Scrum framework, while at the same time alleviating some of the team's stress level by high turnover at the top. We used a Sprint 0 only once and only for this purpose, which in this case, I think was warranted.
12/3/2015 2:22:35 PM

Mike Cohn
Hi Harish--

Good point. And this change in mindset regarding a relaxing of the rules is the most dangerous thing about a sprint zero.
11/13/2015 7:45:59 PM

Harish Reddy
Good article Mike. Every action can be written as a story and added to a backlog. With this as an approach the so called "SPRINT 0" activities can be managed in SPRINT 1. The "SPRINT 0" for some reason provides a mindset to relax or abuse the SCRUM rules.
11/13/2015 5:25:26 PM

Lauren Thomas
We did not have a sprint 0 for the latest project we are working on. Our first two sprints have had one or two user stories the rest has been technical foundation items. I feel we knew the tables we were going to need and we we are having design discussions that I feel a sprint zero would have been a better place for both of these.
11/11/2015 1:42:01 PM

Patricia Wong
Our organization has used a "Sprint 0" as a preparatory time for new-trained teams who have stepped out of formal training class to get experience in creating and grooming their product backlog. It does give them more confidence prior to embarking on the transition from waterfall to Agile Scrum. They appear to be more ready for Sprint 1 than teams who have skipped the Sprint 0 here.
10/16/2015 11:46:03 AM

Robert Day
In the Magical World of Scrum, "Great! Let's start right now! First shippable product in ten working days' time!" is ideal. But as others have pointed out, organisations have inertia, and bureaucracy, and sometimes regulatory boxes to tick. And this is why many people still see the need for Sprint 0.

I see nothing wrong with the idea, as long as Sprint 0 really is a Sprint. The shippable product of Sprint zero is a business case, or a project proposal, or some other deliverable that may not be deployable on a server but which can still be put in front of a project board or other colleagues, so they can sign up to it. And then the real work begins!
8/26/2015 4:34:34 AM

Mike Cohn
Thanks, Tiago. I’m glad you liked this.

Most teams treat “Sprint 0” as kind of an “all rules are off” type of period. For example, they don’t necessarily have anything potentially shippable at the end of it. And, they may not estimate all the work they do during it.

None of this is what I advocate. I actually do not like Sprint 0. I don’t like defining architecture up front. I believe those types of things can be done in the context of building the functionality. Not at exactly the same time, but not “ahead” either. I’ve written about that in “Succeeding with Agile” in much more detail than I can in a blog response.

So, given that you want to do one, follow the tips above and if you find the work hard to estimate, don’t estimate it. For the type of work you probably have that early in the project, you are probably better off *timeboxing* that work, anyway. That is, say, “We will spend up to n days (or hours) thinking about (designing) this thing and that’s enough. Then we’ll move on.” So, you don’t really estimate that work, you budget it instead.
8/15/2015 8:49:48 PM

Tiago Galvao
Hi Mike, congrats for the article, I`m huge fan.

Ihave a question... in my case, I`m just about to start a new project and I was sure that would be ok to have de Sprint 0 to define architecture, for the first time we`ll create some class diagrams to facilitate the development and map services. Now after this topic I`m quite sure that I`ll incorporate all this task at the first sprint then, but I would still have one doubt about how could it be estimated, once no other projects have been treated like this and we are not sure about how long it would take or the best frameworks to use for this project. How should it be measured?
Thanks a lot!
8/15/2015 2:34:26 PM

Piyush Dhangar
I feel pre-work will always be required, even to chose Scrum as methodology is part of pre-work.
7/28/2015 1:29:33 AM

Mike Cohn
You're welcome, Hemant. I'm glad you liked this post. I apologize for my slow reply.


I don't recommend putting points on work that a team does in a sprint 0 (if they do a sprint 0 at all). If the team argues that they want "credit" for work done in a sprint 0 then they probably don't really need a sprint 0 in the first place. (And that would be my preference, anyway.)

My experience is that on most new teams I can start to get a sense for where velocity be after 3-5 sprints. Statistically, you'd need at least 8, but with as little as 3 you should be able to start making *educated* guesses for most teams.

I would always express velocity as a range, though--especially with a new team. And the range should reflect the uncertainty you feel about the velocity.
7/26/2015 11:49:05 PM

Hemant Kothiyal
Hi Mike,

First of thanks for writing another great topic.

I totally agree with you on this. But my only confusion is what about story point size for such pre work? Whether we should do it or not? Do we need to consider such work for teams velocity? How long we should wait on velocity to derive release schedule?
7/7/2015 7:24:54 AM

Mike Cohn
Thanks, Arif.

F.J. -- Note that I'm not opposed to analysis work and this type of thinking occurring. I'm just saying that it can almost always happen while at least some programming+testing type work is occurring.

That is, early sprints can be skewed towards thinking rather than doing. But early sprints should not be entirely about thinking.
6/25/2015 11:31:05 AM

Arif Kazi
Nice Article Mike.
In my experience with large clients in BFS, Retail and Telecom world kind of agree with comments from Bandukwala.
Adding to the list
1. Just enough high level architecture alignment with concerned teams/ technical stakeholders
2. In case of multiple organizations contributing to the program, gaining alignment and support from these teams

A good Agile practice like Release Planning helps achieve many of these objectives.

Again the PRE GAME should needs to be time boxed and should follow the agreed iteration length
6/24/2015 5:48:58 AM

F J Bandukwala
Why preparatory phases are required for projects -
1. Management is not willing to commit to starting the project without having a view of total scope and cost.
2. A business case is required to make a decision whether to go ahead with the project at all.
3. Multiple stakeholders need to agree on the scope of the deliverables from the project before it is sanctioned.
6/17/2015 8:49:38 PM

To leave a comment, please login with your scrumalliance.org credentials.

 

Newsletter Sign-Up

Subscribe