Skip to main content

Concept of Sprint Zero

Last post 08:15 pm February 13, 2024 by Iryna AZAROVA
12 replies
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).


02:04 pm February 13, 2024

Atul Godse

Scrum does not address project initiation or planning efforts

Scrum doesn't require the predictable classical project life cycle, such as initiation/planning/executing/finishing. This is because Scrum is a typical adaptive framework. If you prefer practicing a Gantt chart, budget estimation, and classical resource planning, feel free to explore the Waterfall approach! However, refrain from mentioning sprints and Scrum, and disregard agility in responses to the changeable business environment and many other advantages of Agile


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.