Cómo sabemos, Scrum está compuesto de roles, artefactos y eventos. De los eventos hay uno que siempre se nos escapa: el Sprint. Consideramos evento a una reunión, y dado que el no es una reunión como tal, nos solemos olvidar de él. Sin embargo, el Sprint es el corazón de Scrum ya que marca el latido del Scrum Team.
Un Sprint es un periodo de tiempo inferior a 30 días en el que el Scrum Team debe entregar un incremento de valor de su producto “terminado” y potencialmente desplegable. El objetivo es producir valor, lo ideal es llevarlo ante el usuario final para contrastar si es valor, aunque esto es una decisión del Product Owner. Aunque el Product Owner haya manifestado que el incremento no subirá, el Development Team sigue siendo responsable de dejar el código listo para subir ya que en caso contrario aumularán deuda técnica.
Los Sprints tienen una duración fija que debe estar acorde al negocio que tenemos. Cuanto más pequeño sea, mejor para realizar antes inspección y adaptación de nuestro producto. En ciertos contextos se necesitan de más duración porque con menos tiempo no se puede generar incremento que pueda ser desplegado.
Sprint por Semanas
La mayoría de equipos se plantean hacer Sprints por semanas; esto genera un dilema muy típico¿días laborables o naturales? Si es laborable será más fiable, pero corremos el riesgo de perder la costumbre del día de la semana que empezamos; además, en muchas empresas los viernes suelen ser menos horas con lo que si cae ese día una planning podemos tener menos tiempo. Si son días naturales, ciertos Sprint se verán afectados por días de fiesta. Tomad la decisión en equipo y no te obsesiones con la perfección de los números, no hay solución definitiva.
Una de los errores más graves que podríamos cometer es alargar un Sprint a mitad del mismo. Esto es un problema por varios motivos. Por un lado, en la Planning habremos fijado nuestra estratégia para la duración del Sprint que íbamos a ejecutar. Si cambiamos la duración a mitad, tiramos a la basura el trabajo que invertimos en crear nuestro plan. Otro riesgo de hacerlo es que perdemos datos de lo que somos capaces de hacer en un Sprint. Además, puede ocurrir que acabemos entrando en el mundo del caos cuando los variamos su duración constantemente.
Un Sprint siempre empieza cuando termina el anterior. No hay tareas entre Sprints ni se espera a ningún rol. El Sprint ha empezado en cuanto termina el anterior y debemos adaptarnos a dicha situación. Para comenzar un Sprint preparados, lo ideal es hacer refinamiento.
El objetivo del Sprint
Todos los Sprints contienen un Sprint Goal. El Sprint Goal se obtiene en la Sprint Planning y debe ser inamovible. El objetivo debe fijar el incremento que queremos para nuestro producto. Además del Sprint Goal, el equipo hará una previsión del alcance (conjunto de PBIs) que cree que se abordarán en el Sprint. Cuando empecé a aprender Scrum siempre me decían que el alcance se fijaba y no se podía modificar. Esto no es cierto ya que, al ser una previsión (y no un compromiso) es totalmente renegociable. Precisamente es habitual que aparezcan cambios y que el software emerja, por tanto, el alcance siempre es negociable entre Development Team y Product Owner.
Los Sprints terminan de dos maneras: cuando expira su tiempo (time-box) o cuando se cancelan. Cancelar es una acción del Product Owner que es poco común. Suele ocurrir cuando el Sprint Goal se queda obsoleto, lo que puede pasar por un cambio en el mercado, en la dirección de la organización o una tecnología. Si se decide cancelar el Sprint, se acepta el trabajo finalizado y se comienza uno nuevo.
La calidad
Cuando estamos en un Sprint, tenemos un objetivo de Calidad recogido en nuestro Definition of Done. Este objetivo se debe mantener durante todo el Sprint. Es decir, evitar situaciones como “dejemos los test para más adelante que no da tiempo”, “revisar el código no aplica porque este Sprint es crítico” o “entregamos esto aunque no funcione bien”. Disminuir nuestro objetivo de calidad provoca que nos engañemos, que creamos que vamos mejor, que no seamos transparentes con nosotros mismos y que acabemos perdiendo la confianza. ¡No lo hagas!
Y estas son las características del Sprint. Son muchas porque es el corazón, marca el ritmo del equipo por lo que tiene una importancia vital. Parece bastante fácil trabajar asi, pero muchos equipos cuando abandonan Scrum acaban por eliminarlos pensando que así se mejora la agilidad del equipo. “no hace falta pararnos, así somos más ágiles”. La agilidad no es solo ir rápido, también es pararse, pensar, y mejorar. Para ello, la inspección y la adaptación es clave y trabajar con timebox ayuda a ello.
¿Cuál es el tamaño de los tuyos?
