Concept of Sprint Zero

Last post 05:58 pm September 28, 2016
by Piotr Wegert
11 replies
Author
Messages
01:00 pm September 15, 2016

Hi Everyone,

I sincerely apologise if this topic is discussed before but I have some confusion around the concept of sprint zero and wondering if anyone can help clarify this.

Now I do understand there is no sprint zero within scrum. But what should we call the process where we create the initial product backlog items so the team can pull those items to work on their first sprint?

Also, for the sake of argument if we do call the process of setting up the team and creating initial product backlog items etc etc as sprint zero then what is the best practise around the duration of sprint zero? Should we try to use a timebox for this event as well?

Would highly appreciate some comments around this to help me understand this better.

05:31 pm September 15, 2016

"Sprint 0 is like Casper, the friendly ghost. Well-meaning, but creepy." -- Nitin Khanna.

Although, discussed before, this remains an ever popular question. You may simply call what you're describing as "initial product backlog creation" or "refinement" or something that makes sense to the audience. This may depend on your Organization, culture and agile maturity seen.

For the sake of argument (or collaboration?) --
A Sprint has formal connotation. i.e. it has -- Planning, Daily Scrum, Review & Retrospective. If you're using the term "Sprint" I would imagine it includes these.

I would try to figure if there's something else (terms) that can be used to describe the initial team formation. This, again, is subjective and you'll probably get some more opinions further below.

Timeboxes are great! They help keep focus and can be used during an initial team formation as well.

The initial Sprint may be a bit bumpy, but it helps people to get into a rhythm as well as produce a small increment, however so this may be described with relation to the Sprint goal.

Hope some of this helps.

06:17 pm September 15, 2016

Hi Nitin

Thank you for your valuable response. Just to get your thoughts on the below quote, that if we do planning, daily scrum, review and retrospective for sprint zero, then do you not think we need to have an increment as well at the end of sprint zero?

A Sprint has formal connotation. i.e. it has -- Planning, Daily Scrum, Review & Retrospective. If you're using the term "Sprint" I would imagine it includes these.

07:10 pm September 15, 2016

Per the Scrum Guide:

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.

A sprint therefore must have a sprint goal where something valuable to the business is delivered, however small that may initially be.

The initial sprint will likely contain much more grooming activity to prepare a backlog of PBI's than future sprints. What is important is to ask what can initially be done, and then begin working on that item.

Again, if we're being asked to treat the first sprint like an actual sprint (per Scrum Guide), then why refer to it as "Sprint 0"? Just call it Sprint 1, and get started!

08:34 pm September 15, 2016

During my preparation for PSM I, I read somewhere that initial product backlog is created during the process of Product Planning. Usually Product Owner and Stakeholders are involved in such a process, if scrum team is not yet formulated.

This process involves creation of epic size stories, i.e requirements spanning over months, for product backlog. It can be refined to release level stories also.

This initial PB can act as an input to Sprint 1 sprint planning where stories are refined to tasks and sprint backlog is created.

I hope this will be helpful.

08:47 am September 16, 2016

Hi Momin,

as you have said there's no Sprint 0. I think what you are looking for is the concept of Inception. Inception is a phase where you form the team, develop a common vision and a mision for the product, develop some initial business and technical strategy, get the funds to start the product, analyze some risks, etc. This phase is clearly detailed in the process decision framework DAD.

One way or another they are problems that should be addressed. Since the contexts are very different, there is no single solution. It is possible that many of these aspects will come already solved and maybe you are only worried about the creation of the initial Product Backlog. In such case you can have just a harder Sprint Planning Meeting, that is, you can set an 8 hour timed-box meeting to establish a plan of what and how to build as the first Increment.

02:57 pm September 16, 2016

One opinion . . .
Regardless of what it is called (other than using the term Sprint), some minimal time might be needed to help the product effort have a strong start and produce value during the first Sprint. These activities can include crafting and sharing a vision, initial Product Backlog creation, Scrum Team formation and familiarization, and environments (development, build, testing, staging, source control, tools, etc.). Perhaps some or all of these will not be necessary. As noted already, there is no prescribed answer.

12:05 am September 17, 2016

Thank you all for providing some insight and sharing your experiences.

01:58 am September 17, 2016

> Now I do understand there is no sprint zero within scrum.
> But what should we call the process where we create the initial
> product backlog items so the team can pull those items to work
> on their first sprint?

You can call it whatever you like, but not a Sprint. To be a Sprint some value must be released, no matter how small, in a clearly time-boxed manner.

The challenge is to effect initialization in such a way that sprinting, and the delivery of value, can begin as soon as possible. In theory, you only need enough work on a Product Backlog to start one genuine Sprint. The rest of the backlog can be refined on a just-in-time basis. However, this increases certain risks (such as a failure to prepare enough work for the next Sprint Planning session), and so a rolling horizon of (say) two or three sprints' worth of work might thus be observed.

02:32 pm September 19, 2016

Hi,
I'm agree to say there is not sprint0.
There is a first phase called the Setup. During the setup phase, you build your different environment of work, and you build your backlog. In first you build EPIC and enought User Story groomed to begin the sprint 1.

10:36 pm September 21, 2016

There is nothing as Sprint 0... period.

This concept got traction few years back as everyone was trying to solve all issues in scrum framework. If we see project management life cycle (PMLC), scrum falls in more into execution phase. Scrum does not address project initiation or planning efforts. Many experts now talk about creation of vision document and road map as precondition before starting scrum. Scrum also consider "highly motivated team" is available at the beginning.

It may not be scrum master but project manager activity but some initial planning and team formation and on-boarding process is still required. Once team has required ingredients, team can start Sprint. In first sprint, team can take up any small business function/ story and complete it. Goal of any sprint has to be delivering (may be small but) working software. Scrum team begins their journey with sprint 1 under guidance of SM and direction of PO while using many engineering practices.

... open for further discussion/ disagreement!

Thanks

05:58 pm September 28, 2016

Hi Momin,

Now I do understand there is no sprint zero within scrum. But what should we call the process where we create the initial product backlog items so the team can pull those items to work on their first sprint?

Call it whatever you like (Kick off, Prep, Setup, etc) or simply don't call it at all to avoid confusion, just get the necessary stuff done before starting your first Sprint. The concept of "Sprint 0" is not only a practice not present in the Scrum Guide but it can be considered a harmful anti-pattern as it establishes precedences that can bite you back later on. The two most common excuses that come along with "Sprint 0" is that it doesn't have to deliver business value and that it can be extended as many times as needed. If you allow those in "Sprint 0" someone might be tempted to use that as a precedence in the future saying "Hey, but we didn't deliver any business value in Sprint 0, we should be fine not delivering any in Sprint 18" or "Let's extend this Sprint for just one week, we extended Sprint 0 for a month and we were fine". On the other hand if you plan to follow all rules why call it "Sprint 0"? Prepare enough PBIs for one sprint and start clean with "Sprint 1".

Also, for the sake of argument if we do call the process of setting up the team and creating initial product backlog items etc etc as sprint zero then what is the best practise around the duration of sprint zero? Should we try to use a timebox for this event as well?

Hard to come up with a best-practice for an anti-pattern ;) but if you'd like to timebox this process (regardless how you call it) consider sending a clear message on what will happen when the timebox ends and you don't achieve everything that was planned (regarding team composition, Product Backlog, etc).