Agile Forest

In a recent tweet,

If you must do some pre-project prep, so be it. Please don’t name it “Sprint 0” that makes it seem valuable. It isn’t.

Delving further into the tweet I learned that “many use Sprint 0 to enable bad habits” (don’t disagree), that it maybe should be called “project chartering” instead and that a more common definition of a Sprint is “a time-box for delivering a Product Increment”.

So what is the common goal of a Sprint 0?

The Sprint goal (by my definition) behind a Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable”. If you are ready to deliver business value then Sprint 0 is officially done.

Do all projects need a Sprint 0?

I say projects here quite deliberately as a team that is already functioning and already delivering are highly unlikely to need a Sprint 0 unless a specific set of features coming up dramatically impacts the ability to deliver business value inside of the Sprint.

If your organisation is onboard the DevOps train and XP practices are well established then you may not need a Sprint 0. If environments can be created and built upon in a day, if standards and frameworks are well understood then you may be ready to start delivery business value straight away.

This ultimately is highly dependent on your organisational capabilities.

Where does story elaboration fit in with respect to Sprint 0?

Teams quite commonly use the time whilst in Sprint 0 to also elaborate further the User Stories for the first value delivering Sprint.

You don’t have to have elaboration one Sprint ahead, but it can potentially help reduce carry overs, reduce time spent in Sprint Planning and ensure that task cards (if you use them) are well defined.

In an ideal world User Stories would be small enough and complexity low enough that carry overs are minimal and elaboration can occur within the Sprint.

What cadence activities should occur in Sprint 0?

Sprint 0 should be, from a process perspective, exactly the same as any other Sprint. It should be planned upfront through Sprint Planning, work should be broken down into items that are achievable within (ideally) 1-3 days, it should be slapped up onto a story wall/task board and tracked, Daily Scrums should talk about what everyone is doing and enable collaboration and sharing. At the end of the Sprint you should demonstrate what you have achieved within the Sprint Review, “Hey take a look at this box, this is the box that builds our code and automatically deploys it. Here look at it compiling and this is the result (good and bad) that it generates”. The Product Owner may not care but I can assure you the rest of the team will. Additionally it is a great opportunity to start reflecting about how you have worked together as a team and see what can be improved.

Just as per other Sprints the work that is done in Sprint 0 should be prioritised. If it doesn’t enable you to deliver software in a Sprint then it probably isn’t high in priority.

So in essence, all the standard, normal Sprint activities that occur when business value is delivered should also occur in Sprint 0.

How long should Sprint 0 be?

Just like value delivering Sprints, Sprint 0 should be timeboxed. The ideal value to set this timebox to is the same duration of your value delivering Sprints. When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process – were you able to achieve what you had planned?

The trouble with this is that in almost all cases the team’s velocity has not been established and consequently the likelihood of not delivering to expectations is high. If you are going to fail on estimation versus delivery (which I can safely say you will) then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message? How long will it take for pressure to be pushed onto the team?

For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This is where the concept of “Sprint 0” as a term fails and you see people then try to fix it through using “Sprint -1”, etc. This slippery slope further erodes management trust.

I fail to see a magic bullet for this particular problem other than having good planning upfront and always asking “do we really need to do this to begin delivering value?”

What if the team is able to deliver value earlier than then when the Sprint will end?

Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates. If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint.

What if the team is unable to deliver value by the end of the Sprint?

If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little. If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now?

How long after Sprint 0 is finished should you wait to start doing Sprints?

Don’t wait. Get started delivering that value!

Where does team onboarding fit in?

The day you start Sprint 0 is the day all the team should be onboard. Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops.

What are the common pitfalls of Sprint 0?

The obvious one is that teams never get started delivering business value. They stay in this mode of never being ready and there is no drive or motivation to move out of it. Sometimes this is for very valid reasons, for example, developers don’t have PCs or an environment to work in; but often it can be just rats and mice outstanding.

This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner.

So what is the Scrum Guide definition of a Sprint?

The Scrum Guide defines a Sprint as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

So by the above definition it is wrong to call everything that I have said above a “Sprint” because it doesn’t result in a potentially releasable product.

But the Scrum Guide goes on to say:

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective.

which aligns with the above activities that should occur as you prepare to deliver business value. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity (the initial backlog creation being a great example).

What’s in a term?

If you should have for Sprint 0 a Sprint Planning Meeting, Daily Scrums, dev work, Sprint Review and Sprint Retrospective why would you not have a term for this special case that does reflect the word “Sprint” in it, after all, three of the cadence activities in them have the word “Sprint” in them.

If you want to use a different term, lets say “Project Chartering” then you are still having a Sprint Planning, Sprint Review and Sprint Retrospective… but not in a “Sprint”. This seems a little odd and misleading to me.

I feel that the messaging to people starting Agile should be clear and simple and removing the word “Sprint” does not align logically with that. I feel that the word “Sprint” is incredibly applicable and that the definition of “Sprint” in the Scrum Guide needs some common sense flexing of interpretation. I don’t expect the Scrum Guide to change, but do expect some guidance somewhere about how this pre-Sprint is a special exclusion from the delivering of value component in the guideline.

You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.

So what would I call it? I agree that the ‘0’ in ‘Sprint 0’ is misleading. I would call it something like ‘Delivery Enabling Sprint’. Make the implicit explicit.