I see a lot of different posts on LinkedIn and other sites occasionally bemoaning the idea of a sprint zero. These posts generally compare it to a project kickoff where the project charter is discussed and the project plan is presented. And almost all of them posit that sprint zero is a Bad ThingTM or anti-pattern. But IS a sprint zero an anti-pattern or can it be useful?
What Is Sprint Zero?
In traditional project management, there is an initiation or kick-off phase that begins a project. Many people use sprint zero as a way to do a lot of this kind of pre-project work. This could include establishing the version of the IDE (integrated development environment) that the team is going to use. Or deciding on what technologies to use. Or agreeing upon a vision for the project. But in all cases, the idea is the same – let’s get some of the stuff that isn’t really functional work out of the way before we start working on the project.
What Is an Anti-Pattern?
Anti-patterns are sort of the opposite of best practices. They are those behaviors and activities that prevent a team from being able to fully embrace an agile mindset and work in an agile way. Wikipedia’s definition is that it’s more than just a bad habit, bad practice, or bad idea:
A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones. – Wikipedia
I once had a Scrum Master who planned and tracked the stories in a sprint on a day-by-day basis. As in “you’ll work on this story from Monday through Wednesday and then start this other story on Thursday” kind of tracking. While I understood the intent – ensuring that the team could deliver on their commitment – the mechanism was an anti-pattern. It was the complete opposite of how we wanted the team to work. When confronted with this, the answer was “well, we’ve always done it that way”1.
Anti-patterns are pernicious, though, and they seem to make sense when we think about them. We did them before and that seemed like a good idea then; why wouldn’t we do it now? Because it prevents the team from being able to reduce their work in progress, focus on delivering the most important items first, and delivering full and complete value to a customer (internal OR external) by the end of the sprint.
Sprint Zero As An Anti-Pattern
The general concern about sprint zero is that it is used to do a lot of things that we want to delay until later. In agile, we want to “maximize the amount of work not done”. Sprint zero can result in extra overhead and extra work that we want to either delay until later or not do at all. One example would be defining the architecture and design of the system before beginning any work.
Another thing to be cautious about is over-planning the project work. There should be some discussion of the Planning Onion elements, but we want to keep our backlog of features and stories appropriately refined. The things we need immediately should be well-defined; the stuff farther back should be broad strokes and outlines – nothing too detailed. If the backlog gets filled up and well-defined, we know that we’ve got a problem.
Finally, we don’t want to fix our scope and our dates for the project. In traditional project planning, we define the scope of each deliverable and when we complete it or deploy it. In an agile environment, we can either fix the date and float the scope (most common) or do the reverse – but never both! While we might do release planning in sprint zero, we want to follow good guidelines for estimates and planning.
Sprint Zero Thoughts
One of the benefits of doing something like sprint zero is that it gives you the opportunity to establish the ground rules for the team. You should craft your working agreements, including your Definition of Ready and Definition of Done. The team should determine what’s going to be used for the backlog – some tool like Rally, Jira, or VersionOne – and start working on putting items in that. Building out the infrastructure needed to create the product. This could be building automation frameworks (like Jenkins) or the servers to host the different environments.
There’s always work that needs to happen before a team can really start delivering fully-formed user stories. And whether that happens in what you call “sprint zero” or takes up most or all of your capacity in sprint one – at some level, it’s just nomenclature. And it may just be a moniker, but the mindset is important. We need to make sure that we’re maintaining an agile mindset when thinking about this. Tackling small chunks of work that we can actually deliver in the context of a short time-box.
The concern, of course, is that you don’t want to do some of the project management tasks that normally occur before a project kicks off. No big design up front (BDUF). No project plans or GANTT charts. That kind of thing. But getting a team ready to work? That’s perfectly sensible.
We commonly use sprint zero to help a team get started with a client. It’s important that we get the newly-formed team and the client on the same page at the start. Sprint zero gives us the opportunity to flesh out a backlog, get our infrastructure set up with access rights, VPNs, etc. All of the things necessary to get started on delivering a product.
Sprint zero can be an idea fraught with danger if not done properly. And whether you call it project initiation or sprint zero or even the first sprint, getting a team together for the first time and aligned around the vision of the product and the backlog is critical. Without it, the team is taking a road trip somewhere in a car they don’t know, with who knows how much gas, and to God-knows-where. Alignment is key in large projects and small and sprint zero can help get that much-needed alignment.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)
- R Admiral (ret) Grace Hopper described this as “the most dangerous phrase in business”.