Plantilla de retrospectiva de sprint para equipos de ingeniería

Por qué la mayoría de las retros no producen ningún cambio

Las retrospectivas de sprint tienen un problema estructural que las plantillas no resuelven: los equipos generan ideas de mejora pero no las revisan. La retro produce cinco elementos de acción. La siguiente retro arranca con la pizarra en blanco. Los mismos problemas vuelven a salir.

La plantilla de abajo integra la revisión en la apertura para que no se pueda omitir. Ese único cambio hace más por la efectividad de la retro que cualquier ajuste de formato.

La agenda (copia y pega esto)

Duración: 60 minutos para un sprint de 2 semanas; 45 minutos para un sprint de 1 semana Formato: Facilitado, con un tablero compartido async (Miro, FigJam, Notion — el que uses)


Sección 1 — Revisión de elementos de acción (10 min)

  • Lee uno a uno los elementos de acción del sprint anterior
  • Marca cada uno: Hecho / En curso / Descartado (breve razón para los descartados)
  • Arrastra cualquier elemento incompleto; no lo vuelvas a debatir ahora

Sección 2 — Snapshot de datos (5 min)

  • Velocidad del sprint frente al objetivo
  • Trabajo no planificado que superó un día
  • Incidentes o eventos de guardia
  • Cambios de alcance a mitad del sprint
  • Pon los datos en pantalla sin debate todavía

Sección 3 — Qué salió bien (10 min)

  • El equipo añade puntos async antes de la reunión o en los primeros 3 minutos
  • Discute los 2 o 3 más destacados; omite los que tienen acuerdo obvio
  • No pierdas tiempo en cosas que no son accionables

Sección 4 — Qué mejorar (15 min)

  • Mismo formato: aportación async, debate sobre los puntos con más señal
  • Por cada punto: ¿ocurrencia puntual o patrón recurrente? Solo los patrones se convierten en elementos de acción
  • El trabajo del facilitador es convertir "esto fue frustrante" en algo específico y modificable

Sección 5 — Elementos de acción (15 min)

  • Cada elemento debe tener: descripción, un responsable (no "el equipo"), fecha límite
  • Apunta a 2 o 3 elementos como máximo; más de eso diluye la responsabilidad
  • Arrastra los elementos incompletos de la Sección 1

Cierre (5 min)

  • Valoración rápida +/-/delta sobre la retro en sí
  • Confirma que el resumen sale antes del final del día

Lo que los formatos de retro más populares se saltan

Start/Stop/Continue y Qué Salió Bien/Qué Mejorar/Elementos de Acción son ambos formatos válidos. El problema no es el formato; es que las plantillas raramente codifican el paso de revisión al inicio. Ese paso es lo único que crea continuidad de responsabilidad de una retro a la siguiente. Sin él, la retro es una máquina de sentimientos, no una máquina de cambio.

Las plantillas tampoco abordan la disciplina del tiempo. "Qué mejorar" se alarga casi universalmente porque es más emocionalmente estimulante que "qué salió bien". Sin límites estrictos, una retro de 60 minutos se convierte en 90 minutos de debate y 5 minutos de elementos de acción apresurados al final. Los elementos de acción son la única parte que cambia algo.

La tercera brecha: los elementos de acción se redactan como directrices vagas. "Mejorar la comunicación entre frontend y backend" no es un elemento de acción. "Sarah programará una sincronización semanal de 30 minutos entre los líderes de frontend y backend, empezando el próximo lunes" sí lo es. El responsable y la fecha de inicio tienen que nombrarse en la sala; después, los detalles se suavizan.

El coste acumulado de estos patrones aparece semanas después como contexto que nunca se capturó y decisiones que se vuelven a debatir. El impuesto de las reuniones cubre cómo se ve esto cuantitativamente a lo largo de un trimestre.

Por qué los resúmenes de retro son más difíciles de escribir que las notas de standup

Los resúmenes de standup son cortos. Los resúmenes de planificación de sprint son estructurados. Los resúmenes de retrospectiva son difíciles porque el contenido es desordenado: notas adhesivas, discusiones que saltan entre secciones, una mezcla de sentimientos y datos. Quien escribe el resumen tiene que reconstruir un hilo coherente de una reunión que se movió en múltiples direcciones a la vez.

Pavleur maneja esto bien precisamente por ese desorden. Captura todo lo que se dice durante la reunión y lo que aparece en pantalla: el tablero compartido, el gráfico de velocidad de la Sección 2, el ticket de incidente que alguien mencionó en la Sección 4. El informe post-reunión es estructurado, con elementos de acción extraídos de lo que realmente se decidió en la sala (con responsables y fechas, tal como se nombraron). Sin reconstrucción, sin limpieza posterior a la llamada.

Las herramientas de transcripción solo de audio capturan las palabras pero no el contexto visual. En una retro, lo visual suele ser lo más importante: el tablero de notas adhesivas, la gráfica que puso de manifiesto un patrón, el ticket que ancló una discusión. Ese contexto no existe en un resumen solo de audio. Para una comparación directa de herramientas: Pavleur frente a alternativas.

Modos de fallo comunes en la retro

El mismo elemento de acción aparece en tres retros consecutivas. La Sección 1 es innegociable. Si un elemento sigue sin completarse, o se descarta con una razón explícita o se escala; no lo arrastres indefinidamente.

La discusión se convierte en desahogo sin resolución. El trabajo del facilitador en la Sección 4 es traducir "ese proceso está roto" en una cosa específica y modificable. Si no puede hacerse específico en 30 segundos, va al aparcado.

Nadie añade puntos async antes de la reunión. Envía el tablero 24 horas antes. Siémbralo con 2 o 3 puntos para romper el problema del lienzo en blanco. Las reuniones van mejor cuando todo el mundo llega con algo escrito.

Plantilla de retrospectiva de sprint para equipos de ingeniería | Pavleur