Scrum Assessment Discussion > Sprint 0
There is no such thing.
Ken
Ken Schwaber
I have always struggled with the notion of Sprint 0. Most teams I coach rationalize the Sprint 0 as a time to "get up to speed" with the project they are about to take on. This might be getting familiar with a new technology, sizing the project user stories, release plan activities, setting up environments and so on. Ideally these are activities that happen starting in Sprint 1 and that sizing and release planning are just meetings that have already taken place. Bundling this all up under a Sprint 0 heading feels like a cope out.
Ken - I would be interested in your feedback, more than just "There is no such thing". :-)
Jack Harvey
The only purpose a Sprint 0 serves is to allow delays in progress. By requiring that teams produce some increment of working functionality every Sprint, the team is required to prioritize its work so it doesn't waste time over-building the best environment known to man while its company's competition races ahead in the marketplace.
What better way to get familiar with a new technology that by using it to actually build something useful? How can a team realistically size user stories if it hasn't actually worked on any to know how complex they will be? Release plan activities are performed by the PO during the Sprint...he has no data to base a release plan on until at least one Sprint has been completed. Good data doesn't come until after 3-4 Sprints.
A Sprint 0 is exactly that, a cop out. Don't let it happen.
Ken Schwaber
So, is Sprint 0 time boxed ? The answer is No. Am I correct ?
I understand the points of view above, but want to find the simple answer to the assessment question.
Neil Chatterjee
Great. Ken says there is no such thing as a Sprint 0; the assessment asks if Sprint 0 is time-boxed (implying there IS such a thing); this question, "At a minimum, what is necessary to start a Sprint using Scrum?" has the answer of (E) none of the above are necessary - including (D) which is Vision and Product Backlog - which in turn implies that you can have a Sprint with absolutely no value to strive for (without product backlog what the heck are you doing sprinting... unless it's a "Sprint 0"?).
BTW, in the original book by Ken and Mike B, Ken describes the process of starting a new project from scratch and having to put enough into the Product Backlog to give the Team something to Sprint to... "The Product Backlog does not have to be complete; it only needs to include enough top priority items to drive the next few Sprints." Ok, if that's the case case then the question to "At a minimum, what is necessary to start a Sprint using Scrum?" should not be "none of the above" - sounds like the only justification for a Sprint is building a potentially shippable increment of valuable functionality based on the prioritized Product Backlog (however incomplete).
So.. NO there should not be a Sprint 0. But then why is there more than one assessment question that states or implies that there is such a thing as Sprint 0 (a "sprint" that is not based on product backlog per se)?
I think we need more QA on the current PSM assessments and the material supporting it.
Craig Heartwell
"There is no Sprint 0" and "to start a sprint, there doesn't have to be a product backlog" - at least not on paper or excel (or flipchart or whiteboard or ...). I fully agree with both statements. There should be someone (the product owner), who knows, what should be done. At least by and large.
In the first four hours of your Sprint 1 planning meeting (let's assume it's a 30 day sprint) the product owner can present his most important requirements (fresh from his brain). You're starting the product backlog right there. The team asks for clarification (if needed) and estimates the work needed. Then the development team commits to as many of the items with the highest ROI from that fresh product backlog as can be done in the first sprint. And here we are, in the middle of a regular sprint.
Yes, doing that, you might end up not implementing the items with the highest ROI in the first sprint. But if the product owner knows about the product to build, the first handful of requirements that come to her/his mind might be ones with pretty high ROI. And it's better to have something with a pretty high ROI after the first 30 days than having nothing with the highest ROI after 30 days.
With that approach, you can kick off a team pretty fast and the product owner can use a part of the first thirty days to complete his product backlog (and craft an eloquent and accurate vision).
If no one knows any requirements or vision for the product, there might be the question of why that project exists at all.
Cheers
Boris
P.S.: Of course, you can't do that, if the product owner is an intermediary, not knowing anything about the product to build.
Boris Bäsler
Is "Sprint 0"a timebox? what do you think about it?
i dont think it is.