Retrospectivas: 5 formatos y cómo elegir

Sirve para: mejorar cómo trabajamos (flujo, comunicación, herramientas, hábitos), no para reescribir el producto entero ni para echar culpas.

No sirve para: performance review individual, status al stakeholder, ni “desahogo sin cierre”. Si alguien necesita un feedback personal, es otra conversación, en otro momento.

En el ciclo de Scrum, la retro cierra el sprint: planning → ejecución → review → retrospectiva. En Kanban no hay sprint, pero sí conviene un ritual periódico (cada 1–2 semanas) con la misma regla de acciones concretas.

Equipos entusiastas salen de la retro con 12 mejoras. A la semana no hicieron ninguna. Mejor:

• Elegí las 1 o 2 acciones de mayor impacto y menor esfuerzo.
• Cada acción tiene un dueño (una persona, no “el equipo”).
• Cada acción tiene fecha de check (el próximo planning o la próxima retro).
• La retro siguiente empieza revisando si se hicieron — si no, no sumes más deuda de mejoras.

1. ¿Es la primera retro del equipo o hace meses que no hacen? → Start / Stop / Continue.
2. ¿Hubo roce, cansancio o un sprint “pesado” emocionalmente? → Mad / Sad / Glad (con facilitación cuidadosa).
3. ¿Entró gente nueva o el foco fue aprender? → 4Ls.
4. ¿Están planificando un trimestre o un lanzamiento grande? → Sailboat.
5. ¿El sprint fue un incendio y nadie entiende qué pasó? → Timeline.

Rotá formatos cada tanto: el mismo ritual 20 sprints seguidos adormece al equipo.

Agenda de 30–45 minutos que funciona:

1. Check-in (3 min): una palabra de cómo llega cada uno.
2. Recuerdo de acciones anteriores (5 min): ¿se hicieron? ¿qué aprendimos?
3. Generación silenciosa (8 min): cada uno escribe en el formato elegido antes de hablar (evita el anclaje al primero que habla).
4. Agrupar y votar (10 min): temas, no monólogos.
5. Acciones (10 min): 1–2, dueño, fecha. Listo.

El facilitador protege el tiempo y el tono. No tiene que ser un Scrum Master certificado — puede rotar. Si el planning y el daily ya están sanos, la retro suele ser más corta y más concreta.

• Las acciones de proceso viven en el mismo tablero que el trabajo (columna “Mejoras” o etiquetas), no en un doc huérfano.
• Si una acción es grande, partila o no la aceptes: una retro no es un segundo backlog de producto.
• En el próximo planning, reservá capacidad explícita si la mejora come tiempo real (por ejemplo, “limpiar el backlog 1 h”).

Si siempre elegís Scrum o Kanban y la retro no mejora el flujo, el problema puede ser la metodología o el WIP — no el formato de la reunión. Ver Scrum vs Kanban.