Sprint retrospective: guía completa — 24 actividades y juegos de retro + plantilla de agenda

La sprint retrospective es la reunión de balance que un equipo Scrum celebra al final de cada sprint para examinar cómo se hizo el trabajo — qué salió bien, qué falló y qué única cosa se mejorará el próximo sprint. Evalúa «cómo trabajamos»; la sprint review evalúa «qué construimos».

La versión de 30 segundos

Frecuencia: una vez al final de cada sprint, justo después de la sprint review;

Duración: sprint de dos semanas → 60–90 minutos; sprint de una semana → 45 minutos;

Resultado: 1–2 acciones de mejora con responsable nombrado y un criterio de cierre verificable (no un montón de «la próxima vez más atención»);

Señal de salud: si las acciones de tres retrospectivas seguidas aterrizaron de verdad, el proceso está mejorando de verdad.

Agenda estándar (versión de 60 minutos)

Tiempo	Segmento	Propósito
0:00–0:05	Apertura y calentamiento	Marcar el tono: seguridad, los hechos y no las personas
0:05–0:15	Recoger datos	Todos anotan hechos y sentimientos del sprint (con los marcos de actividad de abajo)
0:15–0:30	Generar insights	Agrupar y votar; sacar a flote los 1–3 temas más importantes
0:30–0:50	Decidir acciones	Convertir los temas en acciones concretas: quién hace qué y qué cuenta como terminado
0:50–0:60	Cierre	Repasar las acciones de la última reunión, confirmar que las de esta entran al tablero

El mayor modo de fracaso de la retrospectiva no es el silencio incómodo — es «qué buena charla, y nadie sigue las acciones». Las acciones van al tablero del sprint y se tratan como cualquier otro elemento de trabajo.

24 actividades y juegos de retrospectiva

A. Marcos clásicos (de sobra para la rotación diaria)

Start / Stop / Continue: qué empezar a hacer, qué dejar, qué seguir. El más simple y universal, vale para cualquier equipo;

4Ls: Liked, Learned, Lacked, Longed for;

Mad / Sad / Glad: orientado a emociones, bueno para destapar problemas de moral;

Velero (Sailboat): viento = viento a favor, ancla = frena, rocas = riesgos, isla = meta. Muy visual; encaja en hitos de proyecto;

KPT: Keep / Problem / Try; popular en equipos de estilo japonés, estructura limpia.

B. Actividades centradas en calidad

Mapa de defectos: agrupar en la pared los defectos del sprint por módulo y localizar a simple vista las zonas catastróficas; discutir si es un problema de diseño o de proceso;

Línea de tiempo del rework: listar cada tarea interrumpida o rehecha y perseguir la causa raíz (¿requisitos confusos? ¿entorno inestable? ¿informes sin contexto?);

Un bug memorable: cada uno cuenta el defecto más absurdo del sprint y su causa raíz — mucho más eficaz que la discusión abstracta.

C. Juegos rompehielos para animar (la categoría de «retro games»)

Dos verdades y una mentira: cada uno cuenta tres cosas que pasaron este sprint, una es falsa; los demás adivinan;

Parte meteorológico con emojis: resume tu sprint con emojis;

Ruleta del hablante: sortear al azar al siguiente hablante, para que no hablen siempre los mismos;

Máquina del tiempo: imagina que dentro de un año miras el proyecto de hoy, y escríbele una carta al equipo actual.

D. Cazadores de causas raíz

5 Porqués: encadenar cinco «porqués» al problema más votado;

Diagrama de espina de pescado: atribuir causas entre personas, proceso, herramientas y entorno;

Pre-mortem: supón que el próximo sprint fracasó; escribe de antemano el «informe de fracaso» y retrocede hasta lo que hay que prevenir.

E. Para equipos remotos

Post-its en pizarra online: el clásico de tres columnas (FunRetro / EasyRetro / Miro), notas anónimas + votación;

Escritura silenciosa y después debate: cada uno escribe solo durante 3 minutos primero, y luego se pasan los puntos — evita quedar anclado al primer hablante;

Voto térmico: cada uno tiene 3 votos para los post-its que más quiera discutir; solo los 2 primeros entran en debate;

Por turnos y por grupos: los equipos grandes discuten primero en grupos pequeños (breakout rooms), luego se juntan y presentan.

F. Variantes para mantener la frescura

Puntuar el sprint: darle una nota del 1 al 10 y explicar por qué no es más alta;

Chequeo de objetivo: fijar el Sprint Goal en la pared y discutir la contribución real de cada trabajo a la meta;

Intercambio de roles: los desarrolladores hablan por el PO, el PO por QA — dos minutos cada uno;

Círculo de agradecimientos: cada uno agradece públicamente a un compañero una ayuda concreta; buen cierre, repara el ánimo;

Microexperimentos: empaquetar las acciones como experimentos: «probar X este sprint, y en la próxima retro decidir con los datos si se queda». Menos presión de compromiso, más fácil de aterrizar.

Cómo escribir acciones que nadie olvida

Malo	Bueno
«Reforzar las pruebas»	«Recorrer la checklist de publicación antes de cada release, ejecutada por el QA de guardia de la semana; comprobar el índice de cumplimiento en las dos próximas retros»
«Reducir la comunicación inútil»	«Los informes de bug van solo por el registro compartido; en el chat se pega el enlace sin describir el problema; control sorpresa el próximo miércoles»
«Mejorar la calidad del código»	«Añadir un hook de lint pre-commit, configurado por el responsable de backend antes del viernes»

Rasgo común: responsable nombrado, fecha límite y criterio de cierre verificable.

Apoya la retrospectiva con datos, no con impresiones

«Este sprint la calidad fue mala» — las conclusiones impresionistas así solo provocan defensas. Que hablen los datos cuantificados:

Total de defectos del sprint, por módulo y severidad;

Tiempo medio de corrección por defecto, número de idas y vueltas;

Origen de los defectos (pruebas internas / reportes de usuarios beta / reportes de usuarios en producción).

Estos números necesitan un registro de defectos único — no arqueología en los chats. Los informes de BugCapturer llegan con anotaciones de captura y errores Console/Network (ver la función de diagnóstico) y se empujan automáticamente a un canal de Slack / Microsoft Teams como punto único de seguimiento; una tabla dinámica por módulo/severidad/estado arroja los números de arriba — exporta una tabla antes de la retro y la materia prima del mapa de defectos (actividad 6) y de la línea de tiempo del rework (actividad 7) queda lista.

FAQ

P: ¿Cuál es el propósito de la sprint retrospective? R: Mejorar continuamente la forma de trabajar del equipo. La Guía Scrum es explícita: el resultado es un plan de mejora ejecutable, no una simple catarsis emocional. P: Retrospective vs Review — ¿en qué se diferencian? R: La Review presenta el incremento de producto a los stakeholders; la Retrospective examina el proceso de colaboración (solo el equipo). Ambas son necesarias; no las fusiones. P: Con solo 3 personas, ¿vale la pena la retro? R: Sí — acórtala a 30 minutos: 5 de recogida, 10 de votación, 15 de acciones. Los equipos pequeños cambian de proceso más rápido, así que el beneficio es aún mayor. P: Siempre vuelven los mismos problemas, ¿qué hacemos? R: Significa que las acciones no aterrizan o no tienen responsable. La próxima retro empieza repasando públicamente el índice de cumplimiento de las acciones anteriores; si hace falta, mete «acciones de mejora aterrizadas» en la Definition of Done. P: Demasiadas quejas, el ambiente está pesado, ¿cómo se maneja? R: Cierra siempre con algo positivo: círculo de agradecimientos o nota del sprint. Y asegúrate de que cada retro produzca al menos una conclusión de «seguir haciendo» — una retro no es un tribunal.

Extensión del navegador

Insertar el Web SDK

Compartir enlace

Contexto automático

Equipos y miembros

Proyectos y dominios