Sprint Retrospective (Retrospectiva del Sprint)

¿Qué es la Sprint Retrospective?

La Sprint Retrospective constituye una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras con el que aumentar la calidad y efectividad. La Retrospectiva es la forma en la que Scrum plasma el principio de mejora continua en un doble sentido: personas y tecnología.

Su propósito es triple:

1/ Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos, herramientas y la Definición de Hecho. Por eso, la Retrospectiva no es el foro adecuado para hablar sobre el producto como tal o sobre el feedback de producto que los clientes o usuarios hayan podido aportar.

2/ Identificar qué fue bien, qué problemas surgieron y cómo se resolvieron o no.

3/ Identificar mejoras a implementar lo antes posible, pudiendo añadirse al Sprint Backlog del siguiente Sprint. La Guía Scrum 2017 prescribía que al menos una mejora identificada en la Retrospectiva anterior debía incluirse en el Sprint Backlog; esta prescripción ha sido flexibilizada tras la actualización de la Guía en 2020, que solo apunta a la conveniencia de que esas mejoras se materialicen cuanto antes.

El timebox establecido para la Retrospectiva es de tres horaspara Sprints de un mes; si el Sprint dura menos de un mes, lo normal será ajustar su duración proporcionalmente. En esta ceremonia ha de participar el Equipo Scrum al completo: Scrum Master, Product Owner y Desarrolladores.

Ejemplos de mejoras identificadas en la Retrospectiva del Sprint

Incluimos a continuación algunos ejemplos para ilustrar el tipo de mejoras a identificar durante la Retrospective:

• Actualizar la Definición de Hecho para incorporar code reviews antes de que una funcionalidad pase al entorno de preproducción.
• A fin de evitar distracciones, las llamadas telefónicas deben atenderse en una sala aparte.
• Empezar a utilizar Confluence como gestor documental, que ha de recoger la documentación de las APIs.
• Establecer reuniones regulares con el equipo de soporte al cliente para intentar mitigar los problemas de comunicación que hemos tenido.
• …

Formatos para la Retrospectiva del Sprint

Hay una gran variedad de formatos que pueden servir para dinamizar la sesión y hacerla lo más productiva posible para el Equipo.

Aquí te dejamos algunos enlaces.

• Puedes utilizar una o varias estructuras liberadoras.
• Hay formatos muy divertidos, como estos.

Problemas comunes que afectan a la Sprint Retrospective y estrategias de mejora

1/ Problemas de asistencia. Puede suceder que algunos miembros del equipo “pasen” de asistir. Si es así, estaremos perdiendo transparencia en cuanto a la forma en que trabajamos juntos. Todo el Equipo Scrum debe estar presente en la Retro; esto incluye al Product Owner, al Scrum Master y a la totalidad de los Desarrolladores.

Otras veces, puede que stakeholders o personas externas al Equipo Scrum asistan, generando un clima en el que la colaboración sea más difícil. La Retrospectiva es un evento exclusivamente para el Equipo Scrum.

2/ Falta de compromiso con los planes de mejora. A menudo, el Equipo identifica una serie de mejoras, que añade al Sprint Backlog. Sin embargo, el día a día nos puede y la implementación de las mejoras queda relegada a un segundo plano. Nos olvidamos.

En estas situaciones, la siguiente Retrospective puede ser un buen momento para analizar por qué la realización de las mejoras de procesos fue ignorada. Puede que no fueran debidamente tenidas en cuenta durante la Sprint Planning, o puede que el Equipo seleccionara demasiadas mejoras a implantar, que al final quedaron en nada, etcétera. Como regla general, comprometerse con más de una o dos mejoras por Sprint puede ser arriesgado y mermar en exceso la capacidad del Equipo para el Sprint.

3/ Mejoras no accionables. Salir de la Retro con mejoras genéricas no sirve para nada. Pensemos en vaguedades del tipo “colaborar más con los stakeholders” o “mejorar la comunicación”. Como Equipo, guiados seguramente por el Scrum Master, necesitamos indagar en cuáles son los problemas de fondo que afectan a nuestra efectividad y diseñar acciones concretas con las que soslayarlos.

4/ Algunos compañeros no se atreven a hablar. Por el motivo que sea, puede que ser que parte del Equipo no se sienta con la confianza suficiente como para expresar sus opiniones y dar o recibir feedback. Para afrontar estas situaciones, hay múltiples formatos de Retrospectivas que justamente buscan incentivar la participación de todos. Puede ser que, incluso, nos veamos obligados a hacer encuestas anónimas, para luego poder exponer y comentar los resultados.

5/ La Retrospectiva se convierte en una sesión de quejas. En ocasiones, es fácil dejarse llevar por la negatividad y entrar en una espiral de quejas y reproches, en especial respecto a factores externos al Equipo. En estos casos, el Scrum Master debe darse cuenta y revertir el enfoque. El Equipo debe tener el coraje de asumir sus propias responsabilidades y buscar soluciones. No basta con tan solo quejarse.

6/ Nos saltamos la Retrospective. El Equipo tiene presión por entregar y la Retro, como es el último evento y no se refiere al producto en sí, nos la decidimos saltar. Pues no. El hecho de que consideremos que no tenemos tiempo para celebrar la Retrospectiva ya es sintomático e indica que, efecto, necesitamos hacerla. Si el Equipo se muestra reticente a tener Retrospectivas, el Scrum Master debe buscar fórmulas para hacer que estas empiecen a tener lugar, demostrando su valor.  Por ejemplo, podemos articular Retrospectivas muy breves, en las que con una o dos preguntas identifiquemos ya algunas mejoras valiosas para el siguiente Sprint.

¿Dónde se incluyen las mejoras identificadas en el Sprint Retrospective?

Las mejoras identificadas en la Retrospectiva se incluyen en el Sprint Backlog (por cierto, esta es una pregunta típica en exámenes de certificación Scrum).

Como indicábamos más arriba, de acuerdo con la versión anterior de la Guía Scrum era obligatorio añadir al menos una mejora al Sprint Backlog. Tras la actualización de 2020, este requisito se ha suprimido; es decir, un Equipo podrá no incluir ninguna mejora en el Sprint Backlog o incluir varias, según considere. No obstante, pensamos que identificar y añadir como mínimo una mejora al Sprint Backlog, para que se implemente cuanto antes, sigue siendo muy recomendable.  

En la práctica, cuando hay una lista de mejoras, hay Equipos que deciden añadir estas mejoras al Product Backlog, al entender que de una forma u otra contribuirán a aumentar el valor del Incremento, y a la espera de que sean seleccionadas para incluirse en el Sprint Backlog. También es común tener algún tipo de tablero o archivo compartido expresamente dedicado a mejoras procedentes de las Retrospectivas.

< Volver a Scrum