Sprint Zero – Your Context May Vary

I’ve advocated for using “Sprint Zero” a few times on this blog and each time I get some negative feedback. I’m going to continue my crusade in this post but with a twist.

Firstly, recognize that “Sprint Zero” is about ‘hitting the ground running’. That is, getting the team ready to start writing code that implements user stories. That’s it. Sprint Zero is not about doing extended analysis and design. It’s not about writing specifications either.

If you believe your team has enough information and knowledge to start writing code, go for it. Sprint Zero is not mandatory though it helps in the right contexts. I’ve also written about context before. Often, when I see people disagree, they are envisioning different contexts. Thus they are both correct within their contexts — and they are both wrong within the context of the other person.

Example Contexts

There are an almost infinite variety of contexts when it comes to building software systems. I’d like to consider enterprise systems for these examples. I’m willing to agree that for small systems built by stand-alone teams, Sprint Zero is often unnecessary, though it may be beneficial.

Consider these situations:

1. Replacing an existing system with a completely new implementation.
2. Upgrading an existing system using the existing infrastructure and tools.
3. Creating a new system that provides functionality not currently available.

Now let’s consider the knowledge base of the team:

There are four possible scenarios in my simple example. They revolve around the type of software system being built (e.g. CRM, payroll, order tracking, etc.), the tools and technologies being used, and the current software system (if one exists).

Here’s what it looks like in tabular form. ‘Yes‘ indicates the team has experience with the column heading. ‘No‘ indicates they don’t.

Situation 1: The team has plenty of experience. Sprint Zero is not needed unless the business wants something radically different.

Situation 2: The team lacks experience with the current system. Sprint Zero provides an opportunity to assess the features and performance of the current system as the team prepares to make changes. Gathering metrics about the current implementation will be helpful in assuring that system performance doesn’t degrade during the project.

Situation 3: The team has functional experience but lacks the technical skills required by the system. Sprint Zero offers an opportunity to learn how the current was built and how it operates.

Situation 4: The opposite of Situation 3 — technical skills are available but functional experience is lacking. Sprint Zero may not be needed unless the system is highly complex.

Situation 5: The opposite of Situation 2 — functional knowledge is available but technical skills are not. Training will help and should be done before the project begins. Sprint Zero may help in understanding how the current system was built as in Situation 3.

Situation 6: This is the worst case — usually a junior team thrown together to fix or build something. Sprint Zero is strongly recommended!

I’m only scratching the surface of the many contexts — types of situations and scenarios — that occur but you should get the idea. Sprint Zero is not always necessary and it’s goals will vary.

Finally, if the team feels uncomfortable about the project, use Sprint Zero to define stories that will address the team’s concerns and define a path forward. For example, if the team is unsure about the system architecture and design, what can the team do to decide on an approach? Create a task list and turn it into Sprint One.

Some will accuse me of violating agile principles by suggesting that the team work on something other than user stories. Get over it! The goal is to deliver working software to the business. You need to do whatever it takes to get there — and you need to do it sooner rather than later.

photo credit: Megathon Charlie via photopin cc