En las últimas semanas he tenido varias conversaciones relacionadas con la interpretación que hace mucha gente sobre la duración de los sprints en Scrum. ¿Cuál es la duración ideal de un sprint? ¿Pueden los sprints tener duraciones diferentes?
Comencemos por la definición de sprint en la Guía de Scrum.
El corazón de Scrum es un Sprint, un periodo pautado (time-box) de un mes o menos durante el cuál se crea un Incremento de producto “Acabado”, usable y potencialmente entregable. Los Sprints tienen duraciones consistentes a lo largo de un esfuerzo de desarrollo. Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint previo.
Pero, ojo, porque unas lineas más abajo añade:
Cada Sprint puede ser considerado un proyecto con un horizonte de no más de un mes. Como los proyectos, los Sprints se usan para conseguir algo. Cada Sprint tiene un objetivo de lo que se va a construir, un plan diseñado y flexible que guiará mientras se construye, el trabajo y el incremento de producto resultante.
Pues bien, parece que mucha gente interpreta que los Sprints son mini-proyectos con duración, coste y alcance fijados. Hacen un kick-off de ese proyecto, aunque lo llaman Sprint Planning. También hacen, antes de la entrega, una revisión de lo construido y lo llaman Sprint Review. Ah, y durante el Sprint hacen el Análisis Funcional y Técnico de lo que debe entrar en el Sprint siguiente, y lo llaman Refinamiento del Backlog. Eso sí, hacen una revisión de avance del estado diario (Daily Meeting) y una Retrospectiva para mejorar la manera de trabajar, así que ya hacen el proyecto “en Agile”.
Un Sprint no es un mini-proyecto
Imagino que no hace falta ningún dibujo para ver claramente que en esos casos no hay mucho de Agile sino de pequeños proyectos tradicionales (waterfall), uno detrás de otro, y con el agobio para todos los participantes de que lo comprometido para ese mini-proyecto debe estar acabado durante ese mes, no importa las causas de las desviaciones. Por tanto, es muy importante estimar al principio del mini-proyecto (Sprint) y protegerse bien por si hubiera desviaciones. No suena muy Agile eso, ¿verdad?
Hace bastante tiempo escribí sobre qué significa Compromiso cuando usamos Scrum. En mi opinión, “el único compromiso del equipo debe ser con el ritmo sostenible”. ¿Por qué? Pues porque de esta manera desactivamos esa presión constante por cumplir con la planificación y lo cambiamos por la autoexigencia de todo un sistema, formado por todo el equipo y el cliente, que se enfoca en la predictibilidad del trabajo que hacen juntos.
¿Predictibilidad, dices? ¿Cómo puedo conseguirla? Pues como explicaba en este artículo sobre el burn-up chart:
Actualizando el gráfico al final de cada sprint podremos hacernos una idea sobre cuándo, aproximadamente, podrá estar acabada la versión en curso (o el proyecto entero). Para ello es imprescindible que el equipo mantenga un ritmo sostenible. De lo contrario la estimación no será creíble.
De esta manera, nuestras retrospectivas se pueden enfocar a acciones mucho más prácticas que nos ayuden a mejorar los procesos que dificultan alcanzar ese ritmo sostenible.
Cómo conseguir el ritmo sostenible
Si estás buscando el ritmo sostenible para tu equipo, te dejo algunas pistas:
Sprints siempre de la misma duración
Me gusta emplear la metáfora del metrónomo indicando el ritmo de trabajo. Tic, tac. Tic y empieza un sprint. Tac y empieza otro sprint. Y así, indefinidamente. De esta manera, nuestro final del Sprint no debería ser un momento para correr y terminar lo que hemos planificado sino un día más de trabajo en el que, simplemente, hay una reunión para revisar el trabajo que vamos a entregar.
Sprints de una semana
Si aceleras el metrónomo hasta una frecuencia de Sprints semanales, resulta mucho más difícil dedicarse a correr para terminar lo que hemos planificado al principio de la semana, de manera que resulta más fácil entender que nuestro objetivo es encontrar nuestro ritmo sostenible.
La mayoría de la gente a la que propongo sprints de una semana me dice “pero entonces, siempre estaremos reunidos”. Piénsalo un momento. ¿Cuánto tiempo hay que dedicar a planificar el trabajo de una semana? ¿Y a revisarlo? Además, en las retrospectivas, ¿eres capaz de recordar todo lo que ha sucedido durante un sprint de un mes o sólo de lo último?
Planificación iterativa e incremental
Si no tenemos un plan iterativo e incremental, es decir, si no vamos haciendo y entregando versiones de un producto, será difícil que tengamos control sobre el avance del proyecto. Si conectas los dos anteriores consejos con esto, verás que la tensión del equipo ya no está en el trabajo a entregar al final de cada sprint sino en lo que hay que ir entregando según ese plan. Su compromiso no es con lo planificado sino con entregar valor al cliente.
Si obligamos al equipo a que al final de cada Sprint tengamos el pequeño incremento previsto, volvemos al error del principio, estamos haciendo una planificación predictiva y no una adaptativa y perdemos muchas de las ventajas del desarrollo ágil.
Si desacoplas fin de Sprint con entrega de una versión, simplemente te aseguras al final de cada Sprint que haces “Inspeccionar y Adaptar”, es decir, que reflexionas sobre qué estamos entregando (Sprint Review) y sobre cómo lo estamos haciendo (Sprint Retrospective).
Estimaciones
Si tus historias de usuario son pequeñas y las puede probar un usuario una vez entregadas, lo que sucede al final del Sprint es que tendrás muchas cosas pequeñas terminadas, que se pueden entregar. Si nos olvidamos por un momento de cuántas son, lo que nos importa es si tienen sentido o no desde el punto de vista del usuario, ¿verdad? Pues bien, nuestra Sprint Review se puede centrar entonces en validar el feedback temprano del usuario (si lo tienes cerca, hazle una demostración del incremento de producto y anota su feedback).
Además, si te preocupa la predictibilidad, si tienes que responder a la pregunta “¿y esto para cuándo estará?”. Cuenta el número de historias que soléis acabar y proyecta ese número sobre tu backlog, como en este gráfico.
Además del artículo sobre el burn-up chart, quizás te interese este otro sobre cómo hacer proyecciones incluso cuando tu ritmo no es uniforme.
Por otro lado, nuestros Refinamientos y Sprint Planning se pueden centrar en conseguir que esas historias de usuario sean suficientemente pequeñas y no en estimar cuánto tardaremos en hacer ésta o aquella. Estimar cuánto tardaremos en hacer una historia de usuario no aporta valor al cliente, sólo nos lo aporta al equipo si nos queremos proteger de las consecuencias de no entregar el trabajo comprometido.
Piensa que si, además, nuestros Sprints son muy cortos, es un gran desperdicio perder tiempo en estimar algo que sabremos con certeza al cabo de una semana. Podemos emplear nuestro tiempo en hacer un buen refinamiento de las historias y limitarnos a ver si nuestro Sprint Backlog tiene suficientes historias listas para empezar a trabajar inmediatamente en ellas.
Espero que te sirvan estos consejos. Si es así, me encantaría conocer tu experiencia. Y si lo compartes en la caja de comentarios de más abajo, mucho mejor. O por Twitter, o por LinkedIn.
LA FOTO: Esta imagen la usé en una de mis primeras presentaciones sobre Agile. Representa el ritmo sostenible de un ciclista que sabe que si cambia a menudo de ritmo terminará la carrera agotado. Curiosamente, el Sprint de Scrum nos lleva a una metáfora bien diferente, la del ciclista que hace un esfuerzo desproporcionado para ganar la carrera porque sabe que está llegando al final.