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 –

1. 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)
2. 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.
3. 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
4. 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.
5. Development environment for DEV, QA and UAT builds including continuous integration and continuous deployment servers
6. Agree on development standards like code coverage %, code standards, cross browser testing, etc.
7. Finalize the collaboration and communication tools to support distributed agile – video, chat, project management tool, etc.

Although it’s a matter of choice to incorporate Sprint 0, our experience tells us that sprint velocity is higher from Sprint 1 onwards when sprint 0 is maintained.

So I ask again, can you still afford not to have Sprint 0?

Download Distributed Agile Whitepaper