what should be part of Sprint 0?

Question

This is our first Agile project and we plan our Sprint 0 to consist of :

• Release Content Planning : Defining EPICs/MMFs Product Backlog

• Product Backlog Grooming : Breakup of EPICs into stories (as much as possible at that point of time)

• High Level Design and Environment Setup

• Develop 1 or 2 critical stories to have basic framework in place

Please let me know if we need to have anything else and what do you suggest about the duration of sprint 0

Answer 1

Sprint 0 is not a part of the official Scrum Guide. It has arisen as an unnoficial approach to kickstarting Scrum in some organisations.

All that is needed to start Scrum is a development team, a Scrum Master, a Product Owner and a backlog that covers at least 1 sprints worth of work. So some might regard 'sprint 0' as the formation of the team and the refinement of a backlog that covers at least one sprints worth of stories.

With this rapid starting approach the team would need to do things like environment setup and design/architecture within the first sprint. The development team will often then make it clear to the Product Owner that not a lot of business value will be delivered in the first sprint.

The alternative is to have a longer sprint 0 that packs in a lot of setup and preparation work. The danger with this approach is that it can be a bit waterfall. With the sprint 0 replacing the project inception/design phases of waterfall projects.

I'm not a big fan of sprint 0, but I have seen them used a lot. To answer your original question some things that crop up in sprint 0 are:

• Setting up build/continuous integration/source control
• Deciding on a testing approach
• Configuring release automation
• Setting up electronic task tracking tools (like JIRA/TFS/etc.)
• Agreeing on high level architecture
• Agreeing the team's definition of done

Answer 2

We shouldn't call anything a Sprint unless the team is delivering a Done, useable, and potentially releasable product Increment. From my point of view it is a matter of naming, because the reality (at least from my experience) is that this initial stage is a common process in our organizations. The problem with naming is probably setting wrong precedents or habits in the organization. But leaving that aside, my two cents:

• Prepare and prioritise a list of Product Backlog items
• Start defining your Definition of Done
• Define roles (Product Owner, Scrum Master, Development Team memebers)
• Forecast expected Velocity
• Define a Sprint Roadmap based on Backlog priorities and Velocity
• Determine non-functional requirements
• Setup tools and prepare infrastructure
• Prepare MVPs and design patterns. Define architecture
• Trainings where needed

Answer 3

As stated, there is no Sprint Zero. However, there is plenty that can be done before beginning to utilize the Scrum framework that can help create productivity and success.

• Learn Scrum (http://scrumguides.org, http://scrum.org)
• Create an initial Product Backlog, especially by engaging customers
• Prepare environments, especially continuous integration testing
• Create a Definition of Done, the more robust in the beginning the better
• Share the vision, engage the Scrum Team to move together
• Cross train on job skills, Development Team members have no titles
• Enhance domain knowledge
• Review/Establish coding standards and best practices
• Train on technology skills

The dive-right-in or shock approach can be successful, but there is a high risk that a lot of debt will occur and/or not much production-ready software will be produced in the first several Sprints.

Answer 4

I agree with Nacho in principle, but the reality of any [software] project in my experience is that there is a lot of "ground work" that must be very carefully done before anything "visible" can be built upon it. I would treat these preliminary activities as sprints because they're just as fundamental as anything which will follow – no matter what the books say to call them. The "user's stories" might not appear yet because you are building the infrastructure which will be used to fulfill them. It is important at this point to have a broad collection of possible stories – and very careful and explicit analysis of the (usually) existing system that you will be building from and on.

Do not "shirk" this step in any way, even if it "doesn't quite feel like the sprint books say it should."

You can also use this time to build a "hypothetical body of knowledge," analyzing the existing system to see how this-or-that story might be addressed, and investing time to understand various relevant areas of that system. (Note that I am tacitly assuming that there is "an existing system" – there always is.)