Sprint... mucho más que una iteración

Cuando hablamos de Scrum o metodologías ágiles, imprescindiblemente suena el término “Sprint”. ¿Qué hay detrás de esta palabra?

Sabemos que la metodología utilizada por Scrum implica una serie de eventos y normas a seguir dentro de un equipo de trabajo, con el fin de entregar un proyecto en el menor tiempo posible y con el mejor resultado.

Para esto, una de las técnicas es ir planeando desarrollos en iteraciones cortas y de duración fija, en las cuales se puedan ir concretando pequeños entregables del proyecto, para detectar con mayor facilidad, y en el menor tiempo, necesidades de ajustes o mejoras. Generalmente se establecen periodos de 2 semanas para la concreción de una lista de tareas planificadas, pero podría ser más o menos días, dependiendo de la decisión del equipo y el contexto. Estas iteraciones reciben el nombre de “Sprint”.

A continuación, explicaré algunos puntos relacionados a este concepto, los cuales nacen de las teorías de Scrum, así como de mi experiencia personal como Scrum Master en Sodep, en los últimos 2 años.

¿Cómo armar un Sprint?

Antes de dar inicio a un Sprint, existen ciertas consideraciones a ser tomadas. En primer lugar, el Scrum Master o Líder de Proyecto, debe contar con un Product Backlog. Este backlog puede nutrirse de relevamientos realizados con el cliente, o tareas dictadas por el Product Owner. La priorización de tareas requiere especial cuidado, porque sin una planificación adecuada, se pueden ir desarrollando tareas al azar, que finalmente no logran un producto con un incremento en funcionalidades concretas.

Planning

Una vez que tenemos listo el Product Backlog, se realizará la reunión de estimación de tareas con todo el equipo, donde conjuntamente irán analizando las tareas, compartiendo los conocimientos sobre complejidad y funcionalidades requeridas, de modo a estimar el tiempo aproximado que llevará cada una. En base a la estimación que cada integrante designa a una tarea, se fija un valor o “tamaño” promedio para cada ticket. No se debe olvidar en este paso, que el armado de tareas debe encaminar a formar un producto entregable y medible al final del Sprint, con una serie de objetivos concretos y medibles.

En esta reunión también se asignan las tareas a los responsables, y se debe prestar especial atención a las potenciales dependencias entre tareas, que puedan bloquear el avance de otro integrante. Cada participante debe poder iniciar y avanzar con sus tareas, contando con todo lo necesario para el desarrollo.

En el caso de existir requerimientos relacionados, mi sugerencia es asignarlos a un mismo participante, o si esto no es factible o conveniente, hacer notar al equipo de la dependencia de tareas, de modo a darle la priorización correspondiente a las tareas bloqueantes.

Inicio del Sprint

Una vez que el Backlog se encuentra estimado, priorizado y con la asignación al equipo, se puede dar inicio al Sprint!

Según mi propia experiencia, el trabajo en Sprints genera entusiasmo y motivación en el equipo ¿Por qué? Porque el Sprint genera la sensación de estar corriendo una carrera, de estar compitiendo en un juego decisivo, en el que gana todo el equipo al completar las tareas planificadas. Vale destacar que el espíritu de Scrum es el trabajo en equipo, y no apunta a ser individualista, sino que a través de un trabajo colaborativo, se entregue el trabajo prometido.

Avance del Sprint

Esta metodología motiva a todos a esforzarse al máximo por sentir la satisfacción de ver todas sus tareas con el estado “Done”.

Mientras la carrera avanza, debe existir una fluida comunicación y trabajo en equipo, entre el Scrum Master y el equipo. Nada debe quedar oculto, en cuanto a avances y obstáculos, lo cual se logra con los breves Stand Up Meetings, que sirven para que cada participante dé a conocer tres puntos claves:

• ¿Qué estoy haciendo?
• ¿Qué hice hasta ahora?
• ¿Tengo algún obstáculo? ¿Cuál?

Con esto se busca aclarar dudas, ayudar a eliminar las trabas, de modo a que todos puedan continuar fluidamente con sus tareas.

Es importante que el Líder del Proyecto o Scrum Master, dedique un especial esmero en mantener al equipo motivado y conectado al objetivo del Sprint. Esto se logra principalmente eliminando cualquier obstáculo que el desarrollador no pueda resolver por sí solo, y cubriendo al equipo de cualquier interrupción externa que pueda afectar su productividad, y provocar el desvío del objetivo.

Cierre del Sprint

El cierre esperado de un Sprint es llegar a la fecha de finalización con todas las tareas concretadas.

Pueden presentarse situaciones externas al equipo que atrasen el término de alguna de las tareas. Por ejemplo, algún problema imprevisto de conexión de redes que bloquee el trabajo por horas, o alguna tarea perdió prioridad a pedido del cliente y por ende debe descartarse del Sprint, etc. Son experiencias que pueden darse, y deben ser tomadas con calma. Las mismas deben servir como aprendizaje para prever lo necesario de modo a evitarlos en los siguientes Sprints.

Si la planificación estuvo bien hecha, el equipo contará con un producto entregable, tangible y efectivo, listo para ser usado y entregado al cliente. En este punto, podemos afirmar que el cierre real de un Sprint se da recién al momento de presentar al cliente lo realizado, y verlo satisfecho con el producto evaluado.

Y ahora que conocés estos tips ¿estás listo para arrancar?