He podido participar en varias organizaciones que contienen el concepto de Sprint 0 entre sus armas a la hora de desarrollar software. Este concepto lo descubrí en el libro de Carmen Lasa “Métodos Ágiles y Scrum” al que le dedicaba un capítulo.

Durante mi etapa en una consultora asistí a varios de ellos y cómo lo habían diseñado. Aunque había variantes siempre tenían una línea que trabajaba más la parte de experiencia de usuario, otra la parte funcional y otra la técnica. Dentro de este Sprint introducían técnicas como el Inception. Aquí hay un vídeo de mis excompañeros  explicando la técnica.
El Sprint 0 siempre se puede confundir con una etapa previa de análisis, lo cual suscita un debate sobre su conveniencia. Por ejemplo, he visto organizaciones hacer Sprint 0 durante  más de 3 meses para productos que no tendrían tanta vida, lo que retrasa la inspección&adaptación y el tiempo de la entrega al usuario final.
Cómo diría Robert Galen en su libro Scrum Product Ownership si tienes ya un equipo formado y entrenado en Scrum, un Product Owner con la idea trabajada, las herramientas listas, el equipo sentado junto etc… en ese caso quizás no necesites del Sprint 0 y puedas arrancar. Galen decía que pocas veces lo había visto y por eso él entendía que era necesario, aunque no debería de durar más de dos semanas según su criterio.

Eso sí, el Sprint 0 no es parte de Scrum, aunque quizás ayude a Scrum si se utiliza de manera razonada y no entras en una situación de análisis parálisis. Por ejemplo, he visto algunos equipos llenar el Product Backlog con el Sprint 0 y al finalizar este destruir todo el backlog por un cambio en la idea final de algún stakeholder. Si la decisión que tomas a continuación es hacer otro Sprint 0 está claro que estás pensando en una fase de análisis tradicional. Peros si la opción es arrancar el Sprint 1 y utilizar lo ocurrido para inspeccionar y adaptar podemos decir que estás en Scrum. 
Es verdad que el nombre suscita siempre debate. Un Sprint se considera una entrega de valor, y si te dedicas al software debes entregar software para considerar que entregas valor. Muchas veces no se entrega software en el Sprint 0, por tanto, ¿Es valor? A mi me gusta utilizar la palabra útil. Que no se considere valor no quiere decir que no sea útil y por tanto pueda funcionar. Pocas veces he visto arrancar sin algo previo, por lo que en parte, puede ser útil en muchos casos. A mi me gustan otros nombres más apropiados como conceptualización, design product o discovery product pero esto da para debates sobre la tortilla con o sin cebolla.

Donde de verdad está el riesgo del Sprint 0 es en generar falsas expectativas, el creer que por hacerlo ya tienes clarísimo todo lo que va a ocurrir o tratar de dar un precio cerrado a lo que construirás. Mi teoría con cualquier herramienta es que no son ni buenas ni malas, son herramientas y según cómo se usen pueden ser dañinas o beneficiosas. Si usas el Sprint 0 con el objetivo de tener un backlog fijo en el que estará todo claro e inamovible,  es hacer waterfall. Si lo usas como un primer acercamiento, toma de contacto entre personas que se inician en métodos ágiles, o empresas que colaboran puede ser positivo.

¿Podemos integrar las actividades del Sprint 0 en el primer Sprint? Creo que quizás en algunos casos se pueda, entre otras cosas porque muchos Sprint 1 se utilizan para construir una arquitectura inicial con una pequeña prueba funcional. Mientras esto ocurre se podría ir trabajando la visión del producto, el backlog o un plan de releases.
Por último, me gustaría añadir que muchas veces el Sprint 0 es consecuencia de que no existe una relación de confianza suficientemente fuerte para empezar a trabajar con un cliente. Con el tiempo se irá corrigiendo porque desde una perspectiva lean se puede ver como desperdicio: “mi competencia no hace Sprint 0 y llega antes al mercado”. ¿Tendrá sentido el Sprint 0 en mercados cada vez más agresivos que requieran de mayor agilidad?

Entradas relacionadas