¿Como planificar un Sprint en Scrum?

Si recordáis la película, “Atrapado en el Tiempo“, protagonizada por Bill Murray, consistía en una repetición temporal del mismo día. Casualmente era el día de la marmota, famoso en Estados Unidos porque sirve para prever si el invierno va a durar mas o menos tiempo, en función de lo que haga una marmota.

Si la marmota al salir de su madriguera no ve su sombra, dejará la madriguera, lo cual significa que el invierno terminará pronto. Si por el contrario, la marmota ve su sombra y se mete de nuevo en la madriguera, significa que el invierno durará seis semanas más.

El día amanece con un objetivo que es desvelado cuando la marmota ve o no ve su sombra.

Cuando ejecutamos un sprint en scrum, podría asemejarse al día de la marmota, donde el comienzo del sprint se produce cuando suena el despertador y donde el conjunto de acontecimientos que van sucediendo depende de las acciones que el protagonista realiza durante el “sprint”.

Se va adaptando a los nuevos cambios, y orientando todo a su objetivo final que es el de conseguir que la chica se enamore de él, y salir del bucle.

Si asemejamos la ejecución de un sprint a la película, podemos encontrar algunas similitudes.

• Ambos se repiten en el tiempo como un bucle.
• Las acciones principales se repiten día a día si no hay un acontecimiento importante que lo impida.
• El día y el sprint comienzan y acaban en un determinado momento, suceda lo que suceda.
• Ambos nacen con un objetivo, y se llevan acciones para conseguirlo. (Phill quiere enamorar a Rita – En nuestro sprint trabajamos por un incremental de valor del producto)

La planificación del sprint debemos hacerla teniendo en cuenta que una serie de acontecimientos deben repetirse en el tiempo, puesto que son los que nos garantizan una entrega incremental de valor.

Pero debemos adaptarnos a los cambios surgidos en el sprint en scrum.

Si por ejemplo necesitamos hacer estimaciones de tareas que nos requieren mas de 1 hora de reunión, podemos hacer 2 reuniones de refinamiento de 1 hora cada una, en vez de una sola por sprint. O si vemos carencias en el detalle funcional de las tareas, podemos incluir alguna reunión previa al refinamiento del PO (Product Owner) y el SM (Scrum Master) para que se detalle a nivel funcional con mayor profundidad estas tareas.

Es decir, nos vamos adaptando continuamente al cambio, para conseguir un objetivo que es el de conseguir el objetivo del sprint o que Rita se enamore de Phill como en la película que hemos comentado.

Otro punto importante es controlar los tiempos y puntualidad de comienzo y fin de las reuniones. Si observamos que este punto no se cumple, debemos incluirlo en el orden de la retrospectiva para revisar por que esta pasando y adaptarnos. Nos comprometemos con un objetivo considerando un trabajo asumible en el sprint. Si disminuimos el tiempo que podemos dedicar al trabajo no podemos asegurar la entrega.

Si tenemos certeza de la entrega de producto incremental, debemos convocar con suficiente antelación a los interesados principales de negocio que decida el PO, enviándoles una convocatoria de la Review del sprint. En realidad si todos los sprints entregamos valor, los interesados deberían ir cada sprint a la Review. Este es un punto complicado de conseguir, pero clave para conseguir un alineamiento real del desarrollo del producto con las necesidades de nuestros clientes. Comentaremos este tema con mas detalle en otra entrada.

La reunión retrospectiva debe ser variada, para que el equipo no piense que esta repitiendo el día de la marmota cada sprint, dándole dinamismo e incentivando la participación. Podemos encontrar mas detalle en la entrada de como planificar una retrospectiva.

En definitiva, el sprint en scrum debe regirse por unas bases que deben repetirse en el tiempo pero adaptandolas a las propias necesidades del momento en el que nos encontremos.