¿Qué es el Sprint Planning? +🔥 Bonus: Cómo planificar

El Sprint Planning es el primer evento de Scrum en dónde se planifican las tareas a realizar en el Sprint en curso. En esta reunión participan, de manera colaborativa, todo el equipo Scrum: Scrum Master, Product Owner y Equipo de Desarrollo.

Características del Sprint Planning

El tiempo de esta reunión es de máximo 8 horas para Sprints de 4 semanas de duración. Para Sprints de menor duración, esta reunión debe proporcionalmente ser más corta. El Scrum Master es el encargado de asegurar que esta reunión se realice, se enseñe la importancia de la misma, y además debe asegurarse de que se realiza en el tiempo establecido.

La labor del Product Owner es la de describir las tareas con mayor prioridad al resto del equipo, estas tareas deben ser las que aparezcan en la parte superior del Product Backlog. El Equipo de Desarrollo pregunta todo lo necesario para convertir estas historias de usuario en tareas más específicas.

El Product Owner no debe explicar el 100% de los ítems del Product Backlog, es una buena práctica que los dueños de producto se presenten a esta reunión preparados para hablar sobre ítems correspondientes a 2 Sprints.

El Sprint Planning responde a las dos siguientes preguntas:

• ¿Qué se puede hacer en este Sprint?
• ¿Cómo haremos el trabajo elegido?

¿Qué se puede hacer en este Sprint?

En esta parte, el Equipo de desarrollo pronostica su capacidad de desarrollo en el Sprint. El Product Owner explica el objetivo de la iteración, y los ítems del Backlog que se deberían hacer para conseguir el objetivo final. Todo el equipo trabaja de manera colaborativa para comprender el trabajo a realizar.

Entra en importancia el Product Backlog, el último incremento desarrollado, la capacidad del equipo de desarrollo y el rendimiento en el Sprint anterior. Todos los items que se seleccionen del Product Backlog son decisión exclusiva del Equipo de desarrollo.

Durante el Sprint Planning se define el Sprint Goal, que es objetivo que el equipo Scrum debe conseguir para una correcta evolución del proyecto.

¿Cómo haremos el trabajo elegido?

Con el Sprint Goal y los ítems del Product Backlog seleccionados, el equipo de desarrollo decide cómo convertir estas historias de usuario en incremento de producto. Los items seleccionados del Product Backlog reciben el nombre de Sprint Backlog.

Cabe destacar que no es necesario que se planifique el desarrollo del 100% de las historias de usuario, es buena práctica planificar el trabajo de los primeros 2 días, y descomponer esta planificación en varias reuniones, con esto se gana agilidad y productividad.

Al final de la reunión, el equipo de desarrollo debe ser capaz de explicar tanto al Product Owner como al Scrum Master como van a trabajar de manera auto-organizada para conseguir desarrollar todos los items del Sprint Backlog, y conseguir el objetivo definido en el Sprint Goal.

🔥 Bonus: ¿Cómo 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 adaptándolas a las propias necesidades del momento en el que nos encontremos.