Qué es el Sprint 0 y su papel en metodologías ágiles como Scrum

Es muy probable que, si tienes relación con algún proyecto que siga metodologías ágiles (más concretamente Scrum), hayas oído hablar del Sprint 0. Se pueden generar dudas sobre su funcionalidad o qué es exactamente, por lo que vamos a tratar este concepto y las ventajas de Sprint 0.

El término “Sprint 0” genera numerosos debates encaminados a determinar si su uso es adecuado. Para entender esta polémica, se hace necesario contextualizarlo dentro de las metodologías ágiles y, más concretamente, dentro de Scrum.

Una rápida introducción al entorno que rodea lo relacionado con el Sprint 0 pasa por entender qué son las metodologías ágiles. Podemos resumirlas como métodos que buscan simplificar el desarrollo de software, facilitando su gestión y control y optimizando los tiempos (tanto de adaptación como de entrega del proyecto), entre otros beneficios.

Una de las metodologías ágiles más empleadas es Scrum. Brevemente, podemos decir que se basa en establecer una lista de objetivos y requisitos del proyecto, que se cumplen con distintas entregas regulares. Esto es la iteración continua, es decir, el desarrollo de las tareas necesarias en distintos bloques de tiempo fijos para finalizar el proyecto e ir mejorándolo de forma incremental. Se trata de que cada entrega aporte valor con la mayor eficiencia y productividad posibles, mejorando la comunicación con el cliente para adaptarlo a las necesidades del mismo.

Tal y como se ha comentado, en Scrum los proyectos se desarrollan con iteraciones cortas, fijas, regulares y sucesivas. El término empleado para denominar estas iteraciones, plazos o ciclos es el de “Sprint”.

Cada uno de los Sprints que forman el proyecto debe entenderse por sí mismo, como si fuera un subproyecto y, por tanto, con su propia planificación y revisión. Los Sprints tienen una duración máxima fijada (timeboxed), de forma que se mantiene la productividad al máximo siguiendo el ritmo de trabajo.

Un punto clave de los Sprint es que debe dar como resultado un entregable o producto final que funcione por sí mismo, independientemente de los cambios que puedan realizarse a posteriori. El objetivo del Sprint es conseguir un incremento del valor del producto que se pueda presentar al cliente o empresa. Comprender esto es especialmente relevante debido a que es una de las causas que generan más polémica respecto al Sprint 0.

En Scrum no se hace referencia explícita al Sprint 0. De hecho, el coautor Ken Schawber considera que es una “mala denominación” y que realmente se refiere a la planificación que se realiza de forma previa al Sprint 1. En parte, esto se debe a que no genera ningún incremento de valor del producto, algo necesario según la definición de “sprint”. Sin embargo, el uso de esta expresión está tan generalizado que se puede llegar a entender como una parte esencial del proyecto y establecer una definición.

Tal y como se ha dado a entender, el Sprint 0 corresponde a la fase previa al inicio de un proyecto de Scrum. Tiene como objetivo establecer el propósito del proyecto, así como las líneas principales de trabajo. Se crea una estructura básica de metodologías ágiles para que se desarrollen los siguientes Sprints de manera satisfactoria. Durante este periodo, tienen lugar distintas tareas. Algunas son:

• Elaborar la versión inicial del Product Backlog. Se preparan las historias de usuario que se incluirán, fijando las prioritarias.
• Puede incluir tareas de investigación o análisis, incluyendo estudio de requisitos iniciales (por ejemplo, en cuanto a formación, herramientas, seguridad, etc.).
• Se estudia el diseño y la arquitectura, así como los entornos de desarrollo.
• Se define el equipo y los roles de cada persona, preparándolos y organizando también el trabajo a realizar.
• Se hace una aproximación de los plazos y esfuerzos necesarios para el correcto desarrollo del proyecto, definiendo los distintos puntos de entrega (las versiones que se irán mostrando) y determinando también en qué momento se podrá decir que el proyecto ha finalizado, es decir, cómo debe ser el resultado final (conocido como DoD, es decir, Definition of Done o “Definición de completado”).
• Se estudia el Business Case, esto es, aspectos como la viabilidad del proyecto o su rentabilidad, entre otras.

Debido a que esta noción no existe oficialmente en el método Scrum, se puede entender que el desarrollo de esta etapa no es obligatorio. De hecho, se genera polémica en torno a su necesidad por este mismo motivo, ya que no se le considera un “sprint” como tal. Sin embargo, dejando de lado la denominación del mismo, este concepto cuenta con diversas ventajas:

• Permite identificar los objetivos y puntos clave del proyecto, enfocándolo con más exactitud.
• Definiendo el alcance, ayuda a determinar aspectos como la duración, el tiempo o el coste, disminuyendo la incertidumbre.
• Ayuda a tener claras las bases del proyecto y la metodología ágil que se empleará, facilitando su aplicación.
• Permite planificar todo lo que será necesario, simplificando el inicio del proyecto.
• Servirá como guía de planificación del resto de sprints, ahorrando tiempo más tarde.

Como ya hemos visto, el Sprint 0 no forma parte de Scrum, pero puede ser muy útil en determinados casos, por ejemplo, si es la primera vez que se trabaja utilizando metodologías ágiles. Sin embargo, para equipos ya formados en esta materia y con experiencia puede resultar totalmente prescindible.

Quienes defienden el uso del Sprint 0 alegan que no se trata de una simple fase de análisis, exponiendo que, aunque no aporta un valor explícito como resultado del proyecto, esta valía sí se manifiesta en una mejora de la planificación para el resto de los sprints. Dentro de los partidarios de esta etapa, existen quienes consideran que sería adecuado cambiar el término “Sprint”, precisamente por la polémica que ocasiona, mientras que otros defienden que el concepto es correcto por seguir los principios ágiles de Scrum y el resto de los sprints ya establecidos.

Mucha gente niega la existencia de este sprint porque se ciñen de manera estricta a lo establecido en las bases de Scrum. Una posible solución para aquellos que no “creen” en el Sprint 0 pasa por integrar todas las tareas que se agrupan bajo el mismo en el primer sprint (“Sprint 1”).

Sea como sea, existe más o menos un consenso a la hora de afirmar que el Sprint 0 no forma parte de Scrum, tal como demuestran las guías del mismo al no mencionarlo como evento oficial, e incluso como se deja ver en palabras de sus creadores.

Ahora bien, ¿es necesario seguir al pie de la letra lo decretado por la metodología Scrum? ¿Puede que quepa la posibilidad de hacer una excepción con el Sprint 0, aun sabiendo que se trata de una etapa ajena a este método?