Un Sprint es un periodo de tiempo inferior a 30 días durante el que debemos entregar valor al menos una vez. Su duración es clave porque marcan el latido del Scrum Team ¿Cuál es el tamaño recomendado?
Entendiendo el Sprint
A muchas personas les cuesta entender el concepto de Sprint. El hecho de que exista un ciclo de trabajo periódico y continuo choca con la idea de la entrega contínua que fomentamos en las organizaciones. ¿Por qué esperar a que acabe un Sprint para entregar?
Tenemos que entender muy bien que un Sprint es un periodo de tiempo en el que garantizamos que existan diferentes eventos de inspección y adaptación para entender cómo va nuestro plan, nuestros resultados y nuestro equipo. El Sprint asegura que inspeccionamos y adaptamos en periodos cortos independientemente de si hemos entregado o si lo hemos hecho varias veces.
Por tanto, las entregas y la estrategia que tengamos es independiente del Sprint. Esto nos abre un mar de opciones; si realizamos una Sprint Review, siempre será más rico en un equipo que haya hecho entregas y tenga datos que analizar, que en un equipo que necesite varios Sprints para entregar. De ambas maneras se puede realizar la inspección de los resultados (pobres en el segundo caso) y adaptarnos.
¿Por qué 30 días?
Ken Shchwaber y Jeff Sutherland tienen muchos libros a sus espaldas, pero, curiosamente, solo uno juntos: Software en 30 días. En este libro, analizan la importancia de la entrega como punto clave para validar su solución. Un equipo que entrega puede entender mejor los resultados de su trabajo y actuar en consecuencia (adaptarse). Esta es la esencia de Agile y del cambio que se está produciendo en las empresas.
Ahora bien, 30 días puede parecer mucho o poco, en el caso del software suele ser suficiente. Pocos equipos he visto a los que 30 días les resultaran pocos para entregar valor ¡Cuidado! Sí que existen equipos que no son capaces de entregar en un periodo inferior, pero por problemas organizacionales que se pueden resolver.
Y esta es una de las claves de Scrum, levantar las deficiencias organizativas que nos impiden entregar y que, por tanto, nos dan pistas sobre qué elementos de nuestra empresa debemos trabajar, para mejorar nuestra capacidad de adaptarnos y maximizar nuestras opciones de entregar valor.
Cierto es que en equipos con poca experiencia 30 días pueden ser un problema. De hecho, mi opinión es que es mejor hacer Sprints más largos si garantizamos que haya entrega y, después, estudiar los impedimentos que podrían eliminarse para reducir dicho tiempo.
Cambiar la duración
Dijimos que el Sprint es el latido de un Scrum Team, marca su ritmo. Si pensamos en un corazón, puede interesarnos latir más rápido en momentos de más estrés, buscando bombear sangre en periodos más cortos. En momentos más tranquilos, nos puede interesar un latido más suave, que nos permita tiempo para analizar nuestros resultados.
Eso sí, ir más rápido o más lento no es problema y tampoco cambiar de ritmo si vamos a ser consistentes. El verdadero problema son las arritmias, cambiar contínuamente de ritmo el corazón es lo que puede volver loco a nuestro organismo.
Un Scrum Team debe fijar su Sprint y mantenerlo un tiempo razonable cómo mínimo. Puede cambiar, pero cambiar el ritmo lleva tiempo de adaptación (y de ser predecibles). Si es necesario, adelante, pero sin abusar de ello.
¿Cuál es el tamaño recomendado?
Para mí, el tamaño ideal es aquel que garantice que entregamos valor en primer lugar. En tecnologías como Business Intelligence, los equipos optan por Sprints muy largos (3-4 semanas), mientras que en equipos de mobile es más habitual apostar por Sprints semanales. Todo dependerá de tu capacidad de entregar. Un Sprint Largo puede ser necesario, sin embargo, puede generar demasiada tranquilidad en un equipo al que le cuesta entregar.
Los Sprints semanales son muy estresantes, pero tienen ventajas contra los cambios. Si intentamos introducirlos, podemos recurrir a la frase “espera a la semana que viene”. Esto es más complejo en Sprints de cuatro semanas.
Otro factor clave, sobre todo en organizaciones con poca experiencia en Agile, es nuestra capacidad de reunir interesados en la Sprint Review. Necesitamos a personas ajenas al equipo que nos den feedback y nos guíen. Si estas personas están muy ocupadas, va a ser difícil reunirnos muchas veces por lo que Sprints cortos pueden ser un problema.
En conclusión, intenta Sprints cortos siempre que se pueda, garantiza que se podrá entregar (cumpliendo la Definition of Done) y que tendrás interesados en la Sprint Review.
Y tú, ¿qué tamaño de Sprint prefieres?
