Sprint Zero
Cada vez más equipos trabajan con un “Sprint Zero”. Pero, ¿es realmente una buena idea?
Un Sprint Zero se necesita principalmente cuando ciertas cosas deben completarse antes del inicio real del proyecto. Quizás primero haya que formar un equipo u obtener hardware. En algunos proyectos se exige incluso un Backlog separado para este Sprint.
Uno de los mayores problemas con un Sprint Zero es que se establecen reglas diferentes para un Sprint específico o un tipo particular de Sprints. Por ejemplo, en un Sprint Zero, el objetivo del equipo ya no es obtener algo potencialmente entregable al final. ¿Cómo podría surgir algo potencialmente entregable si el objetivo del Sprint es formar un equipo para el desarrollo del producto?
Sprint 0 vs. proyecto previo
En mi opinión, la mayoría de las cosas que se consideran argumentos a favor de un Sprint Zero pertenecen en realidad a un “proyecto previo al proyecto”. Antes de un proyecto de desarrollo, a menudo existe un proyecto separado en el que se decide si debería haber un proyecto de desarrollo en absoluto. Antes de que una empresa comience con un nuevo proyecto grande, siempre debería pensarse primero si ese proyecto debería llevarse a cabo.
La decisión a favor o en contra del Sprint Zero puede considerarse como un proyecto independiente.
Dado que Scrum es un buen marco para la gestión de proyectos, también puede usarse para el proyecto previo al proyecto. En este proyecto previo, los miembros del equipo que ya están definidos (o incluso solo el futuro Product Owner) pueden crear un primer Product Backlog, encontrar miembros del equipo, establecer los requisitos técnicos, etc.
Encuentro útil considerar estos trabajos como un proyecto propio, porque un solo Sprint a menudo no es suficiente. ¿Cómo llamaría un equipo a su segundo Sprint si el Sprint 0 no es suficiente? ¿Sprint 0,5?
En este punto hay que tener en cuenta algunas cosas:
Mantén el proyecto previo al proyecto lo más simple posible. La mayoría de los proyectos de desarrollo ni siquiera necesitan un proyecto previo.
Respeta los principios de Scrum. En la ejecución de un proyecto previo al proyecto, no surgirá nada potencialmente entregable. Y eso está bien. Pero siempre recuerda por qué es un principio tan central de Scrum obtener algo potencialmente entregable al final. Y eso también deberías tenerlo en cuenta en el proyecto previo al proyecto.
