Fundamentos de Scrum Framework: ¿Qué es un Sprint? + Infografía

Fundamentos de Scrum Framework: ¿Qué es un Sprint? + Infografía | Autor: Alonso Álvarez | Ilustraciones de Patricia Parreira.

Este artículo forma parte de una serie en la que revisaremos los fundamentos de Scrum complementados con infografías que los explican. 

Puedes consultar los artículos sobre la Planificación, Retrospectiva, Review y Daily.

Agile tiene un problema con los nombres. Aunque “agilidad” se interprete muchas veces como “velocidad”, en realidad el significado más acertado es el de flexibilidad. ¿Qué es más ágil, un patinete o un tren bala lanzado a toda velocidad?  

En el caso de Scrum hay quien interpreta “Sprint” como una carrera alocada de velocidad punta, cuando en realidad se refiere dar vueltas a una pista con un ritmo adecuado para no quedarse atrás, pero sostenible para poder terminar la carrera y ahí sí, esprintar. 

Scrum es un framework o marco de trabajo -nunca una metodología- con muchos años de recorrido y que ha ido incorporando aprendizajes de distintas fuentes, especialmente de la propia experiencia de los equipos que lo aplican. El Sprint o iteración forma parte de Scrum desde el principio y nunca se ha cuestionado por una buena razón: es el elemento articulador de todo lo demás. 

¿Qué es el Sprint? 

La Guía Scrum de 2020 (más breve en cada edición) dice: “Los Sprints son el latido del corazón de Scrum, donde las ideas se convierten en valor”. Así que sin Sprints, Scrum no late y muere. Queda clara su importancia, pero ¿de qué estamos hablando? 

Los Sprints son “eventos de longitud fija” limitada a un mes, aunque sea habitual fijar el sprint en 2 o 3 semanas. El propósito de estos ciclos o iteraciones de duración fija es “crear consistencia”. Scrum es una forma de trabajo que deja el protagonismo a lo importante que es la creación de valor. Por ese motivo reduce al mínimo la incertidumbre con una serie de reuniones o eventos fijos y establecidos que ocurren en un momento predecible y cuya mecánica es conocida. Hay quien se queja de que Scrum “tiene muchas reuniones”. La alternativa (juntarse a demanda, sin saber de antemano cuándo y con agendas cambiantes) es infinitamente peor.  

El Sprint crea consistencia y reduce incertidumbre para dejar protagonismo a lo importante: crear valor. 

¿Qué pasa en un Sprint? 

Todo el trabajo de la iteración dirigido a entregar ese valor se lleva a cabo durante el Sprint. Para asegurar el alineamiento, y el ritmo sostenible, hay una serie de reuniones que marcan el comienzo y fin de trabajo y la necesaria sincronización del equipo: Planificación, Reunión diaria, Revisión y Retrospectiva, más lo que considere necesario un equipo para su correcto funcionamiento. En total y en el peor de los casos, de acuerdo con la Guía Scrum, queda disponible casi el 90% del tiempo del sprint para realizar el trabajo. El resto se dedica a planificar, detectar impedimentos, contrastar resultados, mejorar la forma de trabajar, alinear al equipo y las expectativas de los stakeholders… 

Cada una de las “responsabilidades” de Scrum tiene un papel relevante durante el Sprint: 

• El PO o Product Owner gestiona el backlog, dialoga con los stakeholders, y atiende al equipo. 
• El SM o Scrum Master busca mantener un flujo de trabajo efectivo preocupándose por la eliminación de impedimentos mientras da soporte como líder servicial y coach del equipo. 
• Los developers (que es el término que usa la Guía, aunque aclara que deben estar todos los perfiles necesarios, y no únicamente programadores) traducen las necesidades de negocio, expresadas como elementos del backlog, en valor para los destinatarios del producto o servicio. 

El Sprint culmina en un Incremento de Producto, o valor agregado al ya existente, aunque no sea necesario esperar al final para poder liberarlo hacia sus destinatarios. 

¿Qué guía el trabajo en el Sprint? 

Cada Sprint arranca con un objetivo que alinea las expectativas, anticipa los resultados y ayuda al equipo a poner foco en lo realmente importante. Para hacer esto, el Sprint se convierte en un entorno estable. Y esto supone no introducir cambios que pongan en riesgo conseguir el objetivo, si bien nada impide que haya un refinamiento y negociación con el Product Owner a medida que se avanza (y aprende) en el trabajo. Y por supuesto, la calidad se mantiene estable y no se discute. 

El objetivo del Sprint marca el rumbo y define el propósito, mejorando la motivación de los miembros del equipo. Por el contrario, carecer de objetivo, de guía, es una situación muy desmotivadora (imagina qué supone el “hay que hacer cosas” sin saber muy bien para qué). 

Claro que puede haber circunstancias excepcionales en las que ese objetivo quede superado o se manifieste inalcanzable y no haya forma de reconducirlo. Es en ese momento cuando se puede plantear una cancelación del Sprint, pero sólo está en la mano del PO hacerlo. 

¿Cuándo dura un Sprint? 

Aunque la Guía Scrum sólo define que el Sprint debe durar “un mes o menos”, la experiencia y la propia Guía nos dice que la duración tiene mucho que ver con el objetivo de reducir incertidumbre y riesgo. 

El Sprint, como ciclo o iteración, ayuda a generar estabilidad pero, sobre todo, a generar aprendizajes.  

Scrum es, no lo olvidemos, “un marco ligero que ayuda… a generar valor a través de soluciones adaptables para problemas complejos”. Si el problema al que nos enfrentamos es laborioso, complicado, pero tiene una receta clara, repetitiva y conocida para poder ser resuelto… seguramente Scrum no sea lo que necesitamos para abordarlo.  

En cambio, si hay incertidumbre, lagunas en la descripción del problema, desconocimiento en la forma de solucionarlo… tendremos que tantear el terreno preguntándonos periódicamente si vamos por el buen camino. Ese es el terreno el que Scrum se desenvuelve con soltura y donde nos va a ayudar. 

La duración tiene mucho que ver con esto. Cuando nos movemos en un entorno de gran incertidumbre, tenemos que revisar con más frecuencia si vamos por buen camino, si tenemos que introducir cambios y ajustes. Un Sprint de un mes implica que nos movemos por terreno muy firme. En el otro extremo, en un entorno extremadamente volátil, podríamos reducir su duración hasta una semana e incluso menos (hay ejemplos de actividades exploratorias con Sprints de un día).  

Es habitual trabajar con duraciones de 2 o de 3 semanas (la Guía expresa preferencia por la duración más corta). Incluso hay marcos de escalado que fijan una duración determinada. El límite temporal que adopte un equipo debería nacer de su propia experiencia y necesidades. Pero lo que debe quedar suficientemente claro es que la duración del Sprint no es ajustable ni se cambia a demanda. El Sprint es un marco fijo y estable, por lo que duración no debe estar sometida a vaivenes. 

El Sprint es el elemento estructural de Scrum, y jugar con su estabilidad vuelve a Scrum débil e inútil. 

Infografía “El Sprint”

También hemos puesto a tu disposición la infografía completa de “El Sprint” a modo de resumen. ¡Consíguela con sólo un clic!