Lo que sabemos y no del sprint en scrum

El concepto de Sprinten el mundo de la agilidad es uno de los más conocidos, la mayoría sabemos loque significa y lo practicamos a diario. Sin embargo es común escuchar y ver queaún existen confusiones, y esto puede llevarnos a cometer pequeños errores al tratarde implementar el marco de trabajo Scrum.

El Scrum Guide nos menciona que “el Sprint es un bloque de tiempo de un mes o menos durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable”. Si tomamos en cuenta esta definición, entendemos que el Sprint comienza con el Evento del Sprint Planning y termina con el evento de “Sprint Retrospective”, esto si queremos lograr tener un producto “Terminado y potencialmente desplegable”. ¿Y que es lo que vemos en muchos equipos practicando Scrum que difiere a esta definición? vemos que el tiempo que dedican a “construir su producto” lo consideran “el Sprint” y a continuación lo mostraré con la siguiente imagen:

A pesar de que estoparece insignificante, aun así puede contribuir a que personas o equipos quevan adentrándose a implementar Scrum puedan confundirse y empezar a seguirmalas prácticas apenas comenzando a vivir esta nueva experiencia de gestión deproductos.

Para aclarar esta confusión hay que mencionar que el Sprint es un sinónimo de “Iteración” y conlleva todos los eventos en Scrum dentro de esa iteración:

• SprintPlanning
• DailyScrum
• SprintReview
• SprintRetrospective

De hecho el mismo “Sprint” es considerado un evento en Scrum y algo más que nos aclara la guía de Scrum es que aparte de contener los eventos previamente mencionados también embebe otro “evento” llamado “Development Work (Trabajo de desarrollo)” el cual es la ejecución de todas las actividades dentro de nuestro Sprint Backlog. Habiendo dicho esto, el Sprint se vería de la siguiente forma:

Sabemos que el time-box propuesto para el Sprint es de dos a cuatro semanas, y viendo el “Sprint” desde esta perspectiva, podemos entender que su duración propuesta incluye todos los eventos de Scrum y no únicamente el “Development Work (Trabajo de desarrollo)” que justo esto es una confusión común. Entonces, ¿las dos semanas del time-box involucran al Sprint Planning, Sprint Review y Sprint Retrospective? y la respuesta es Sí, y Sí, y el impacto de saber esto es alto ya que podemos planear adecuadamente nuestras iteraciones en el tiempo. Para aclarar este punto veamos como se ve un sprint en un calendario por semana:

Aquí tenemos un Sprint1 con duración de dos semanas en las cuales tanto los eventos como el trabajode desarrollo están incluidos. También se puede apreciar como al terminar elSprint 1 el “viernes” de la segunda semana, inmediatamente comenzamos el Sprint2 el “Lunes” con su Sprint Planning. Esto nos lleva a otra característica importantedel Sprint que nos dice que un nuevo Sprint comienza inmediatamente después dela conclusión del sprint anterior, y con esto también estamos viviendo uno delos 12 principios de la agilidad que dice: “Los procesos ágiles promueven eldesarrollo sostenible. Los patrocinadores, desarrolladores y usuarios debenmantener un ritmo constante indefinidamente.”.

Para concluir, otro impacto relevante de entender el Sprint como un conjunto de eventos es la estimación del equipo de desarrollo durante el Sprint Planning, ya que en sus estimados deberán considerar que quizás 1 día y medio o 2 de los 10 días del sprint serán para llevar los eventos de Scrum y no para desarrollar software. Tomando en cuenta estas consideraciones puedo garantizarles que mejorarán su planeación, evitarán confusiones que parecieran “triviales” y los ayudará a tener una mejor percepción del Sprint en Scrum. Me encantaría poder ver en los comentarios si algún lector ha tenido alguna experiencia en cuanto lo que aquí presento, les agradecería lo compartieran y así todos podamos seguir aprendiendo de la agilidad.