Scrum is the most popular project management methodology in the world and if you work in web development chances are good you are using Scrum in some form. A current trend in Scrum is the “Sprint 0”. What is it? Why has it stuck around? And why does it offer little value to the agile project?
Sprint 0 is often what the period before diving into the iterative agile process is called, an initial effort of a team to create the guiding documents required for scrum projects: a vision, a product backlog, and product release estimates.
Most agile experts agree that sprint 0 is not a true sprint, is hard to measure, and doesnt result in a done increment. But it exists for a reason. Many teams adopt them because their project has an unmet need beyond the immediate scope of Scrum. My observation is that sprint 0 is most often used when there is a lack of a strong vision for the project.
The Scrum process, in fact, assumes a clear vision has been developed and communicated by the product owner. However in reality that is too often not the case. Sprint 0 is an attempt by the development team to fill in the vision gap. Agile is great for figuring out the best way to reach a goal, but generating an initial vision is not within its scope. In fact, missing from Scrum altogether is a description of the required vision for the development process to begin.
The real drawback of Sprint 0 is not it’s goal, it’s that building the guiding documents for the project at the time when you have the least information provides low value to the development process that follows. From an agile perspective Sprint 0 isn’t iterative, doesn’t utilize the talents of the whole team, and delivers nebulous results.
A better alternative
Guiding project visions that don’t align with the iteratively emerging reality either need to go through the expensive process of another sprint 0, or more often simply get ignored while development gets on with their jobs. I propose a more agile method of building vision that I’ve used successfully in no-handoff projects: the prototype sprint.
A prototype sprint is a first sprint that engages the entire team while actually building out the initial prototype itself. Brainstorming ideas are translated into a low visual fidelity but working prototype as quickly as possible. The prototype is written in a functional frontend html and css framework, the shared language of the team. Not everyone can understand a spec sheet, everyone can understand a website. In this way communication and contributions can expand to include all disciplines.
By the end of the first sprint the prototype is ready for initial testing across several fronts including general usability, accessibility, and mobile responsiveness. On my teams this is a valid and important done increment. The prototype sprint also produces an initial product backlog. As backlog items get completed in future sprints the prototype gains in fidelity. The prototype is not throwaway code, it’s foundational.
Instead of the vision potentially being an impediment or becoming outdated as soon as development begins, in a prototype sprint the vision and functional criteria are developed together and support one another. And because the vision is generated by the team there is no handoff to the team.
A prototype sprint utilizes the talents of the entire team, generates the necessary vision, results in the team’s first done increment, and avoids project handoff. Through this process teams build shared ownership of the project vision and a stronger foundation for cross-disciplinary cooperation in the agile spirit.