Sprint 0

I searched in the Scrum Guide and found neither stand-alone 0 nor "zero" :)

It was not mentioned at all in the guide so i choose the it does not exist option

Sounds to me like you are dealing with this in the right way.

Sometimes it's tempting to delay starting Scrum until everything is "perfect". That's a very inagile way of starting Scrum, and actually cuts against the Scrum approach of doing inspecting and then adapting.

I would recommend going for it, and learning from a real Sprint, where the team are actually working towards a goal and a releasable increment.

If you chose "it does not exist", this was not the area that you need to work on in order to pass the exam. Many companies use Sprint 0, this is usually brand new teams that have never done scrum at all. They use this for training, getting setup, backlog estimating, etc; basically all of the prep work. It is NOT a convention that is endorsed in Scrum but is used in the real world.

Zachary, as Simon mentioned Sprint 0 is quite tempting and Curtis correctly points out that many organisations "in the real world" still use it. However, think how a Sprint 0 preparation can affect the empiricism of the Scrum framework.

Even in some of the forums i have read on here say that you could call the pre-sprint a sprint 0. i am just looking for clarification on weather this "sprint 0" actual exist in the scrum framework or if it is just a name that some people use to call the pre-sprint but doesnt actual exist.

I wrote a blog on this recently:

https://www.scrum.org/resources/blog/scrubbing-sprint-zero

Thank you everyone who has commented on this I really appreciate the comments in helping me understand this question.

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created - Scrum Guide

So do not call anything a Sprint unless you are delivering  a "Done", useable, and potentially releasable product Increment no matter how small it is ! The idea here is that you choose to deliver at least one thin slice of functionality hitting all layers with the goal of releasing a usable increment while focusing on establishing the initial state of all these layers (which will be continuously be improved through other PBIs in future sprints). So you can inspect and adapt for any potential failures early on.

I’ve been thinking how to phrase my opinion over the last few days so I’m hoping it will make sense. For the longest time I disagreed with the convention of having a Sprint 0. I disagreed because I feel if there is going to be a sprint, an increment must be developed. I recently moved to a company that is transitioning and adopting Agile and they use Sprint 0 for each team. However, Sprint 0 is only used for the newly minted and formed team. Sprint 0 is basically the time when the team members go through the Scrum Training workshop, various interviews are done to determine the strengths of each team member, and start the first backlog grooming sessions. Sprint 0 can be anywhere from 2 weeks to 4-5 weeks, it depends on the team and the product. Once they are trained and the backlog is in a ready state, Sprint 1 starts and they go like normal. Nothing is created in Sprint 0, it’s literally just the forming and training stage.

Here is why I’m okay with them calling it “Sprint 0”. The main reason is because it sets a tone that the team foundation and sets it apart from anything they did previously by calling it “Sprint 0”. The term “sprint” is not used in any other shape or form within our company so for our teams, it acts as a small mind shift away from the old and towards the new stuff.

Some companies use Sprint 0 frequently and more of a crutch than anything to make up for the time and work that the PO chose not to do before hand when a team completes one product and moves to the next. For an Agile Transition/Adoption, I personally think the Sprint 0 is fine, IF it is used in the right context and not just a crutch.

Hope that makes sense.

Curtis, does your organization have any empirical evidence that this approach is less wasteful than delivering something (perhaps small) within the first Sprint, and continuously coaching the team to improve over time, by inspecting and adapting?

Sprint Planning can be 8 hours, so it might make sense to form a definition of "Done" (if none exists) and create the first part of the backlog at that point, then forecast what is known and achievable, while also including training as a continuous improvement item in the Sprint Backlog.

Psychologically, this could be very helpful to a new team, as it reinforces the idea that they must:

1. Deliver a done valuable increment every Sprint
2. Take ownership of their continuous improvement tasks

For an Agile Transition/Adoption, I personally think the Sprint 0 is fine, IF it is used in the right context and not just a crutch.

Sometimes "Sprint 0" is just a name shared by the team.

It is the general name of all activities prior to the first Sprint. These activities may include the composition of the team, training, Release Planning, product version and roadmap, and so on. Many companies call it Sprint 0.

The activities before the "Sprints" were not defined by the Scrum Guide.

After the software is delivered, the activities related to the release or deployment are also not defined by the Scrum Guide.

Perhaps the word "Sprint 0" is easily misunderstood, but as long as the team knows what it means, why not?

Note, however, that Scrum does not have an activity called "Sprint 0."

Just as Scrum won't tell you how to eat.

If the test asks that the Scrum team must use a knife and fork to eat, the answer must be wrong.

Curtis, does your organization have any empirical evidence that this approach is less wasteful than delivering something (perhaps small) within the first Sprint, and continuously coaching the team to improve over time, by inspecting and adapting?

Simon, good call out man. I am sure there is that evidence but being that this is the start of my second week, I have not dived down that deep. I do know from the other coaches here that they have found it is much better to do the Sprint 0 and use it for training and forming the team as opposed to just starting and training as they go in the first sprint. I agree with this because if I'm a developer and I've never used Scrum and all of a sudden Monday morning I'm supposed to start a brand new product, with a brand new team, all the while using a brand new "process" and I have to learn as I go; I'm going to be crazy overwhelmed. Doing the Sprint 0 allows time for the new team members to learn about the process through the workshop (3 days), get to know each other a bit, and get a general idea of the product through the grooming sessions prior to starting the first sprint.

Sometimes "Sprint 0" is just a name shared by the team.

It is the general name of all activities prior to the first Sprint. These activities may include the composition of the team, training, Release Planning, product version and roadmap, and so on. Many companies call it Sprint 0.

The activities before the "Sprints" were not defined by the Scrum Guide.

Ching, I could not have said it better myself. This is exactly what my company does.

I guess on the last point there, Curtis, is, if there have to be activities prior to the first Sprint, is it fair to call it a Sprint? Might calling something Sprint 0 endanger the expectancy that every Sprint deliver a shippable increment?  If it's not delivering a shippable increment, and indeed some sort of 'set up' phase, it should be recognised as such, rather than calling it a Sprint to justify its existence.

I guess on the last point there, Curtis, is, if there have to be activities prior to the first Sprint, is it fair to call it a Sprint? Might calling something Sprint 0 endanger the expectancy that every Sprint deliver a shippable increment?  If it's not delivering a shippable increment, and indeed some sort of 'set up' phase, it should be recognised as such, rather than calling it a Sprint to justify its existence.

Alex, great callout! I think this really depends on the organization and maybe even the team. In my organization, the expectation has been made that Sprint 0 is the foundation building time of the team. The focus is the team, not the product; Sprint 1 is the start of the product work. Just as Ching said, "Sprint 0" is just the name we use and we have found it helps get the people in the mindset of something different. They have not used "Sprints" before so it begins the mindset change that the old is done and dead and even in the team formation we are focused on something completely different.

Could it be detrimental to use Sprint 0 because it can create confusion with the team like you mentioned? Sure but I think if we as Agile Coaches, SM's, organizational leadership have a clear message regarding it; confusion on that will be minimal.

We use Sprint 0 during the setup phase which includes requirement gathering, estimating, solicitation, and customer training on Scrum. This generally spans between 2-8 weeks based on the project. 

In my opinion, this gives an understanding to the clients on how things will move forward and terms that will be used during development. 

Even though Sprint 0 is not mentioned in the scrum guide, it is used in the real world.

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. 

This must only be true, then, for the second Sprint and onwards as Sprint Planning occurs within the Sprint timebox.

Alex, I don't know how all companies do it but with my current company, Sprint 0 is nothing more than the training and boot camp time for a new team. We are in the middle of Agile Adoption and the teams created are brand new and the majority have not used Scrum or Agile. We can call it "Team Boot Camp" or "New Team Orientation" or whatever other term but "Sprint 0" is what we have decided to call it.

The Scrum Guide gives no guidance on the prep-work for a new product, nor does it give guidance on how to pursue an Agile Adoption like this. Sure you can say just start Sprint 1 and try to cram backlog formation, team formation, scrum training, grooming, planning, dev work, review and retro, and develop an increment but that is a big ask for a team that has no clue what Scrum is. Doing all of that within 2 weeks (considering that is the normal Sprint length), presents a big challenge and I've not seen many cases at all where it yielded successful results. In most cases, the scrum team members are dealing with whiplash from being forced to rush into something that they don't really understand. We have found, based on empirical data, that training the team prior to Sprint 1 has yielded a much more successful team and a team that is more willing to fully embrace scrum and agile.

Yes, sorry, I should have been more clear.  My last comment was not in relation to yours.  It was more so identifying a part of the Scrum Guide where an organisation might feel the need for a "Sprint 0" is necessary.

@ Alex, No worries and I fully agree on that aspect with you.

>> We use Sprint 0 during the setup phase which includes requirement gathering, estimating, solicitation, and customer training on Scrum. This generally spans between 2-8 weeks based on the project. 

One reason I am not a fan of Sprint 0 is that some teams tend to fall back on to waterfall habits.  Two months would be excessive for most teams, and to the points already made, there would be no empirical data to prove out any of the requirements gathered over two months.  We also have to respect the Sprint's time-box, and I see most Sprint 0's ignoring that.  And the team doesn't learn to work and produce an Increment within a consistent time-box when we choose a span that differs from what they do after Sprint 0.

All most teams really need is enough ready Product Backlog to fill a Sprint, a few days of training, a day to come up with definition of "Done", norms, etc., and a Scrum Team to get started.  If you have a Scrum Team you could nail down a Sprint's worth of Product Backlog in a day and take 2 days of training, then start Sprinting in a week of less.

I really enjoyed reading everyone's comments, along with the professional dialogue and debate.  Great thread!

I really enjoyed reading everyone's comments, along with the professional dialogue and debate.  Great thread!

Openness

Respect

Courage