Why do you need Sprint 0?

“Give us the project and we will start developing it from day 1”. This sounds great, business value at its best – doesn’t it?

If ‘Start of the project’ to you is defined as “we have our team ready, give me the prioritized backlog, we’ll estimate so we can start developing”, then you can indeed start developing immediately. However in most of the cases, you don’t have a backlog, a team, etc. ready when the ‘GO’ for a project is given. Many a times, you jump into sprints 1,2,3.. to realize that you are not able to ship as much as you wanted because the house was not set in order! Your velocity nosedives and you are a helpless spectator trying to catch up with the promises of the sprint goals.

That is where ‘Sprint 0’ comes into picture.

Sprint 0 is often called ’0′ sprint, because we may have 0 shippable outcomes. This can be confusing for many technology and product managers who view Sprint 0 as a no scope activity with no value add.

Sprint 0 is an essential part of Agile and should be seen as the project before the project. Setting the foundation in sprint 0 ensures that the entire team is dedicated to business stories and is delivering value in subsequent sprints. The outcome of Sprint 0 for the Scrum team should be aimed at reducing mess, reducing uncertainties, and becoming comfortable with the product and processes – all these go a long way in ensuring successful outcomes for forthcoming sprints.

In a typical development project, Sprint 0 would include environment setup of Dev, QA, UAT, backlog grooming, wire-framing of the MVP, setup of CI and other engineering tools, daily sync between onshore and offshore stakeholders, getting involved in discussions, brainstorming to mitigate uncertainties, or even try to get a meaningful first screen out that showcases and validates your tech choices and UX theme.

Here is a list of 6 specific things which product managers, project managers or product owners should ideally plan in Sprint 0. These should give you a good set of deliverables and you should be able to start your Sprint 1 in an awesome way -

Finalizing the technology stack, quick prototyping for 1 or 2 unknown alternative choices: This allows you to be more confident about the non-functional requirement (NFR)

Product backlog grooming for building a sufficient pipeline with just enough refined user stories: This gives you confidence about the rest of the project and the team picks up few critical stories and develops them to completion. Since these are the first few stories, delivering them includes putting the skeleton/framework in place so that even Sprint 0 delivers value.

UX mockups for 1or 2 critical flows: This helps you establish the UX/ UI expectations and includes putting together a flexible framework to make refactoring easy

Preliminary application architecture to start building the application: This includes a basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes.

Development environment for DEV, QA and UAT builds including continuous integration and continuous deployment servers

2 comments

I think, in addition to above 6 points, we need to finalize DOR (Definition of Ready) before committing/planning/taking up user stories for each sprint and DOD(Definition of Done) to confirm that completed user stories meet the expected requirements 100%.

I agree with Ramesh that we need to finalize DOR (Definition of Ready) before committing/planning/taking up user stories for each sprint and DOD(Definition of Done) to confirm that completed user stories meet the expected requirements 100%
I found following two important activities in addition to activities mentioned in this article.

1.) Educating the entire team, stakeholders on “agile way of working” and what is the expectation from every role and how collectively we are going establish the culture of One Team-One Goal

2.)Also, how we are going to estimate across all multiple teams. It is good to have estimation approach known to everyone in Sprint 0 and we can have a “Wall Of Reference” which gives an idea about what is that team has to use throughout sprints such as practices, tools, techniques and this Wall of Reference is a white board or online which gets revised as we progress on agile journey. The Wall of Reference helps anyone to know in simple format how we are implementing agile on our projects.

After all it is journey and Sprint 0 is the somehow minimum preparation of that journey