If you work in web development chances are you are using some form of agile. A current trend is the “Sprint 0”. What is it? Why has it stuck around? And why does it offer so 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 the project: a vision, a product backlog, and perhaps a timeline. Most agile experts agree that sprint 0 is not a true sprint; it’s hard to measure and doesn’t 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 agile.
The agile process, in fact, assumes a clear vision has been developed and communicated. However in reality that is 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 most agile processes is a description of the required vision for the development process to begin.
The 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. Sprint 0 isn’t iterative, doesn’t utilize the talents of the whole team, and delivers nebulous results at best.
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. A more agile method of building vision in no-handoff projects is 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-fi but working prototype as quickly as possible. The prototype is written in a functional frontend framework, the shared language of the team. Not everyone can understand a technical specifications document, or translate a northstar conceptual direction into actionable items; 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.