Todos los métodos
RetroIntermedio

Retrospectiva de Sprint

La Retrospectiva de Sprint es el evento de Scrum que cierra cada Sprint, en el que el Scrum Team inspecciona cómo fue el Sprint en lo que respecta a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado, y decide las mejoras más útiles. Está definida en la Guía de Scrum de Ken Schwaber y Jeff Sutherland y tiene un límite de tiempo máximo de tres horas para un Sprint de un mes, menos para Sprints más cortos. La Guía fija el propósito y el límite de tiempo, pero no una secuencia de facilitación, de modo que los equipos eligen su propio formato para cada sesión.

Duración
45m–3h
Tamaño del grupo
3–10 people
Materiales
Pizarra o pizarra en línea, notas adhesivas y marcadores, las acciones acordadas en la retrospectiva anterior

Guion de facilitación

  1. 1

    Abrir la sesión, recordar su propósito y revisar el estado de las mejoras acordadas la vez anterior.

    10 min
  2. 2

    Cada persona anota en silencio qué salió bien y qué problemas surgieron durante el Sprint, y luego pega sus notas.

    10 min
  3. 3

    Agrupar las notas y dejar que el equipo elija los dos o tres temas que más importan.

    10 min
  4. 4

    Conversar sobre los temas elegidos: qué pasó, cómo se manejó y qué supuestos resultaron ser erróneos.

    25 min
  5. 5

    Recoger posibles mejoras y elegir una o dos que serían las más útiles.

    15 min
  6. 6

    Acordar responsables y el primer paso de cada mejora, añadirlas al trabajo del siguiente Sprint y cerrar con un check-out breve.

    10 min

Consejos

  • Conviene variar de un Sprint a otro el formato para recoger los aportes, por ejemplo Sailboat, Four Ls o Mad Sad Glad, manteniendo el mismo propósito.

  • Hay que comprometerse con una o dos mejoras que el equipo pueda completar en el siguiente Sprint; una lista larga rara vez se cumple.

  • Si facilita el Scrum Master, hay que buscar la manera de que también aporte como miembro del equipo, o rotar la facilitación.

  • La conversación debe mantenerse en cómo trabaja el equipo, ya que el incremento de producto es materia de la Sprint Review.

Errores comunes

  • Acordar mejoras y no darles nunca seguimiento; al cabo de unos Sprints la gente deja de creer que la sesión cambie algo y deja de plantear problemas

  • Usar siempre el mismo formato, de modo que las respuestas se vuelven rutinarias y la sesión se convierte en una formalidad

  • Gastar todo el tiempo disponible en quejas sobre cosas que el equipo no controla, sin dejar tiempo para elegir algo que el equipo sí puede cambiar

  • Saltarse la retrospectiva cuando el Sprint fue estresante, que es justo cuando el equipo más necesita examinar cómo trabaja

  • Convertir la sesión en una búsqueda de culpables; la gente se pone a la defensiva y las causas reales quedan ocultas

Variaciones

Para un Sprint de dos semanas, lo habitual es de 60 a 90 minutos; el límite de tres horas se aplica a un Sprint de un mes. Los equipos que no usan Scrum hacen el mismo tipo de sesión con un ritmo fijo, por ejemplo cada dos o cuatro semanas. Los equipos distribuidos la realizan en una pizarra en línea, o recogen los aportes de forma asíncrona de antemano y usan la llamada para la conversación y las decisiones. Los formatos con nombre propio como Sailboat, Starfish, Four Ls, Mad Sad Glad o Start, Stop, Continue son maneras de estructurar la parte de recolección de datos de este evento.

Casos de uso

Final de cada Sprint en ScrumMejora continua del proceso del equipoRitmo regular de revisión para equipos que no usan ScrumRevisar y adaptar la Definición de TerminadoPlantear a tiempo los problemas de colaboración

Cuándo usarlo

  • Al final de cada Sprint, como último evento antes de la siguiente Sprint Planning

  • Un equipo trabaja con un ritmo regular y quiere un momento fijo para ajustar su forma de trabajar

  • Pequeñas molestias en la colaboración o en las herramientas aparecen una y otra vez y nunca se abordan durante el trabajo de entrega

  • La Definición de Terminado ya no coincide con lo que el equipo hace realmente y hay que revisarla

  • Un equipo nuevo está formando sus hábitos de trabajo y necesita oportunidades frecuentes y de bajo riesgo para corregir el rumbo

Cuándo no usarlo

  • El objetivo es inspeccionar el incremento de producto con las partes interesadas; eso es la Sprint Review

  • Un solo incidente grave requiere una reconstrucción cuidadosa; conviene hacer un After Action Review específico en lugar de meterlo a presión en el espacio habitual

  • Acaba de terminar un proyecto o un lanzamiento largo y se quiere mirar hacia atrás varios meses; conviene usar una Timeline Retrospective con más tiempo

  • El asunto es un conflicto entre dos personas; hay que abordarlo directamente o con mediación, no delante de todo el equipo

  • Los directivos quieren usar la sesión para evaluar el desempeño individual; eso destruye la franqueza, así que la evaluación debe quedar fuera del evento

Métodos relacionados

Lecturas adicionales

Preguntas frecuentes

¿Qué es la Retrospectiva de Sprint?▾

La Retrospectiva de Sprint es el evento de Scrum al final de cada Sprint en el que el Scrum Team examina cómo trabajó y planifica formas de aumentar su calidad y efectividad. Abarca las personas, las interacciones, los procesos, las herramientas y la Definición de Terminado. Con ella concluye el Sprint.

¿Cuánto debe durar una Retrospectiva de Sprint?▾

La Guía de Scrum establece un máximo de tres horas para un Sprint de un mes y dice que el evento suele ser más corto para Sprints más cortos. Muchos equipos con Sprints de dos semanas usan de 60 a 90 minutos. Menos de 45 minutos rara vez deja tiempo para pasar de las observaciones a una mejora acordada.

¿Quién asiste a la Retrospectiva de Sprint?▾

Todo el Scrum Team: los Developers, el Product Owner y el Scrum Master. Las partes interesadas y los jefes de línea ajenos al equipo normalmente no están presentes, porque el equipo necesita hablar abiertamente de su propio trabajo.

¿Cuál es la diferencia entre una Sprint Review y una Retrospectiva de Sprint?▾

La Sprint Review inspecciona el resultado del Sprint, el incremento de producto, junto con las partes interesadas y decide qué hacer a continuación con el producto. La Retrospectiva de Sprint viene después e inspecciona cómo trabajó el equipo. Una mira el producto; la otra, el proceso y la colaboración.

¿La Guía de Scrum prescribe un formato de retrospectiva?▾

No. Describe el propósito, lo que el equipo inspecciona, el resultado esperado y el límite de tiempo. Cómo se estructura la conversación depende del equipo, y por eso existen tantos formatos de retrospectiva con nombre propio.

🪡

Planifica tu próximo taller con IA

Workshop Weaver te ayuda a combinar métodos como Retrospectiva de Sprint en una agenda completa y cronometrada en minutos.

Probar gratis

Method descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020).