Projects do not spring to life fully formed--that is, staffed and ready to be worked on. To address these pre-project tasks, many teams use something that they call "sprint zero." I understand where the idea comes from. Yet, I worry about it. Here's why.
3 Reasons to Drop Sprint Zero
First, though it might be hard to believe, the vast majority of projects can start instantly. I've heard all the claims for things that have to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero. Yet the reality is things like technical environments and an initial product backlog can be figured out during the first sprint--a good, old fashioned sprint number one--while also delivering at least some sort of potentially shippable product increment.
Second, having a sprint zero establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product? The requirement to deliver a potentially shippable product increment exists to help Scrum teams avoid analysis paralysis and to feel a sense a urgency to produce something within the sprint. Just the right amount of urgency can generate greater creativity. The rule also exists to help Scrum teams stay honest--it prevents them from claiming progress when none has been truly made.
Third, on the rare projects that do require
pre-work, what I call the project before the project, that pre-work may take more than one iteration. After all, these must be large projects to truly require pre-work. In that case, we might need a sprint zero, sprint 0.5, sprint 0.75--where does it end?
But We're the Exception. What Do We Do?
So most projects don't require pre-work; that work should be done alongside the development work. But let's say you are working on one of those rare projects that requires a project before the project. How can you ensure the analysis doesn't end up bogging down and becoming more expensive than just starting the project in the first place?
Tip #1: Keep any "project before the project" lightweight. You can even use Scrum to manage the project before the project, working in teams with timeboxed iterations. At the end of each iteration, ask, can we start now, even if it's only on a small scale, and decide on the rest of this as we progress? Often you can find a way if you think creatively.
Tip #2: Finish frequently. Even a team that is only analyzing a potential system can break the work into small, finishable tasks. For example, suppose you are trying to decide whether to create a new hospital system, or what kind of hospital system to create. Rather than committing to "interview all the stakeholders," maybe the team could first decide to interview all the pharmacists about their basic requirements. Once that task is complete, they could interview all of the doctors. Or they could break the work into topical areas: talk to all stakeholders regarding their needs for the prescriptions part of the system. In this case, the team spends the sprint interviewing not just pharmacists but also some medical doctors, nurses, and so on. They don't talk to these stakeholders about anything but the prescriptions part of the system. They'll come back and talk to stakeholders about other functionality in successive interviews. For now, though, this team can be said to be done analyzing needs of all stakeholders involved with prescriptions.
I'll say it again: Most development projects do not need a project before they begin. Almost all of time, analysis work can be completed inside the iterations of the actual sprint. When you do need to do pre-project work, do it quickly, with urgency, and in small fiishable chunks.
Do you want one short tip each week
from Mike to help you succeed with agile?