12 de septiembre de 2026

Retrospectiva de sprint: cómo convertir la reunión en acciones con IA

La retrospectiva sucede, todos hablan con honestidad y dos sprints después los mismos problemas vuelven — porque la mitad de las acciones salen de la sala sin responsable y sin fecha. Veamos cómo registrar la retro y cerrar el ciclo con IA.

Rodrigo Carvalho Rodrigo Carvalho

Retrospectiva de sprint: cómo convertir la reunión en acciones con IA

La retrospectiva sucede, todos hablan con honestidad, el tablero se llena de post-its — y dos sprints después los mismos problemas están de vuelta. Alguien pregunta: “creo que ya habíamos hablado de esto, ¿no?” Nadie encuentra las notas. Todo empieza de nuevo.

El problema casi nunca es la conversación. Es lo que pasa después de ella: las acciones salen de la sala sin responsable, sin plazo y sin un lugar donde alguien vaya a releerlas. Este post es sobre cerrar ese ciclo — con las etapas correctas y con un registro que sobrevive hasta la próxima retrospectiva.

Por qué la retrospectiva suele morir el viernes

Casi todo caso de retrospectiva que no genera cambios cae en uno de estos tres patrones.

La lista sale sin nombre. En una muestra de cientos de miles de ítems de acción de retrospectivas reales, TeamRetro midió que solo cerca del 40% de las acciones recibe un responsable y apenas ~11% obtiene fecha de conclusión. Cuando hay responsable y fecha, la conclusión ocurre en cerca del 90% de los casos. Sin ninguno de los dos, es prácticamente una moneda al aire. Es el mayor vacío medible de todo el proceso — y no cuesta nada resolverlo.

La lista es demasiado larga. Las retrospectivas que terminan con diez o más acciones completan cerca del 56% de ellas; las que terminan con una a tres llegan a cerca del 79%. La lista larga parece diligente y produce el efecto contrario: nada se prioriza, nada tiene urgencia.

Nadie revisa. La acción promedio tarda cerca de seis semanas en completarse. Si el equipo hace retrospectiva cada dos semanas, la mitad de lo que completa lo completa después de que la retrospectiva siguiente ya pasó. Y cerca de una de cada cuatro acciones nunca se completa — casi siempre las que no tienen responsable ni fecha. Una encuesta de la comunidad del PMI, citada por Easy Agile, es más dura: casi dos tercios de los encuestados implementaban menos del 25% de las ideas que salían de sus retrospectivas.

Vale un contrapunto, porque la conclusión fácil aquí sería “la retrospectiva es teatro”. No lo es. La misma medición muestra que los equipos con cadencia regular completan cerca de tres de cada cuatro acciones, mientras que los equipos que hacen retrospectiva de vez en cuando se quedan en torno a la mitad. El problema es la retrospectiva irregular y sin responsable — no la ceremonia.

Las cinco etapas — y el formato correcto para cada sprint

Esther Derby y Diana Larsen codificaron en Agile Retrospectives (2006) el guion de cinco fases que la mayoría de los equipos Scrum sigue hasta hoy. El salto del medio es donde muere la retrospectiva.

EtapaObjetivoTiempo (retro de 60 min)
1. Abrir el juegoCrear seguridad para hablar; alinear el foco de la sesión5 min
2. Recoger datosTraer los hechos del sprint: eventos, métricas, sentimientos15 min
3. Generar insightsSalir del síntoma y llegar a la causa: patrones, “por qués”15 min
4. Decidir qué hacerElegir 1 a 3 acciones concretas, con responsable15 min
5. CerrarRevisar las acciones en voz alta, agradecer, medir la sesión10 min

Saltarse la etapa 4 — o salir de ella con intenciones vagas en lugar de acciones — es la razón más común por la que la retrospectiva no produce ningún cambio.

Sobre el formato: la recomendación estándar es elegir según el contexto del sprint, no por costumbre. Correr Start-Stop-Continue toda semana es la forma más rápida de convertir la retro en un ritual.

FormatoCómo funcionaCuándo usarlo
Start-Stop-ContinueQué empezar, qué parar, qué mantenerSprint rutinaria; el formato más orientado a la acción
4LsLiked, Learned, Lacked, Longed forSprint con bastante aprendizaje nuevo o cambio de alcance
Mad-Sad-GladQué dio rabia, qué dio tristeza, qué dio alegríaSprint tensa; saca la emoción antes de exigir solución
TimelineReconstruye el sprint en orden cronológico y marca los picosCierre de ciclo largo, proyecto o trimestre

Una nota importante: cuanto peor fue el sprint, más importante es la retrospectiva. Es exactamente cuando el equipo está frustrado cuando están disponibles los datos más útiles. Si el tiempo está corto, acórtala a 30 minutos con una sola pregunta — “¿qué cambio tendría más impacto en el próximo sprint?” — en lugar de cancelarla.

La regla de dos: menos ítems, cada uno con responsable y fecha

Toda acción que salga de la retrospectiva tiene que pasar tres preguntas antes de entrar en la lista:

  1. ¿Quién es el responsable? Un nombre de persona. No “el equipo”, no “nosotros”.
  2. ¿Qué cambia exactamente? Un comportamiento, un artefacto de proceso. “Mejorar la comunicación” no es una acción; “Marcus dirige un ejercicio de calibración en la planning del miércoles” sí lo es.
  3. ¿Cómo lo verificamos en dos semanas? Si no existe forma de comprobarlo, el ítem todavía no es lo suficientemente específico.

Aplica el filtro con rigor y limita la lista a una o dos acciones. Una retrospectiva que termina con dos ítems completos vale más que una que termina con doce sin nombre.

Trata cada acción como experimento, no como tarea: “vamos a hacer pairing en los deploys durante los próximos dos sprints y verificamos si baja la tasa de reversión” tiene hipótesis, plazo y criterio. “Mejorar los deploys” es un post-it que va a la basura.

Y el detalle que cierra el ciclo: empieza la próxima retrospectiva revisando las acciones abiertas, antes de cualquier tema nuevo. Cinco minutos, lo primero del orden del día. Si un ítem no avanza, la pregunta útil es si sigue en curso — y no quién es el culpable. Exigir conclusión cada dos semanas genera la impresión equivocada de fracaso en un proceso cuyo ciclo real es de seis semanas.

Cómo entra la IA en la retrospectiva (sin convertirse en acta)

Anotar durante la retrospectiva le quita la atención a quien debería estar participando — y quien anota termina filtrando lo que entra en el registro. Tres usos resuelven esto de verdad.

Captura sin escriba. Graba la retrospectiva (bot en la llamada de Meet, Zoom o Teams, o el audio de la sala) y recibe el resultado estructurado: resumen con headings, checklist de acciones, hoja de ruta de los puntos principales y mapa mental. Nadie tiene que elegir entre participar y documentar.

Revisión del ciclo anterior en minutos. El checklist de la retrospectiva pasada se convierte en la apertura de la siguiente. Lees lo que se acordó, marcas lo que avanzó y preguntas qué está trabado — sin depender de que alguien haya mantenido un documento actualizado a mano durante dos semanas.

Detección de recurrencia. Aquí la transcripción deja de ser acta y se convierte en memoria del equipo. Busca un tema en todas las retrospectivas registradas — “deploy”, “estimación”, “handoff” — y mira cuántas veces volvió. Un problema que reaparece seis veces no es un problema de ejecución: es un síntoma que se está tratando como causa. Y un historial que se puede buscar transforma “creo que ya hablamos de esto” en “hablamos, en tres retrospectivas, y la acción nunca tuvo responsable”.

Sobre cómo capturar reuniones y convertirlas en tareas y decisiones, ya lo detallamos en otro post: cómo planificar el sprint y capturar tareas con IA. Aquí el foco es el ciclo de mejora — y la diferencia entre la retrospectiva aislada y la retrospectiva que tiene historial.

Paso a paso: una retrospectiva registrada de principio a fin

  1. Antes de entrar en la llamada: abre el checklist de la retrospectiva anterior y elige el formato según cómo fue el sprint — no según lo que siempre usan.
  2. Inicia la captura. Pega el bot de Sintesy en la reunión de Meet, Zoom o Teams, o graba el audio de la sala. La transcripción corre en paralelo, sin que nadie pare a escribir.
  3. Corre las cinco etapas con timebox. Da 5 minutos para abrir, 15 para recoger, 15 para generar insights, 15 para decidir y 10 para cerrar. El timebox es lo que evita que la retro se convierta en una actualización de estado.
  4. Cierra con una o dos acciones completas. Di en voz alta: responsable, qué cambia y cómo lo verificamos. Dicho en voz alta, entra en la transcripción; no dicho, se queda en intención.
  5. Deja que la IA estructure. En unos 9 segundos la síntesis está lista: resumen, checklist, hoja de ruta y mapa mental. Sin trabajo manual y sin resumen genérico.
  6. Guárdala donde el equipo vaya a mirar. Fija la síntesis en una carpeta (por ejemplo, “Retrospectivas”). En el siguiente sprint, lo primero de la reunión es esa página — y el chat con IA responde “¿qué decidimos sobre deploy?” sin que nadie vuelva a escuchar una hora de grabación.

Sintesy está hecho para portugués primero, así que reconoce muy bien el portugués brasileño — incluso cuando la discusión es técnica y el equipo mezcla portugués e inglés en medio de la frase. El resultado es una fuente única de verdad que se puede buscar, en lugar de una reunión que se repite en bucle.

Preguntas frecuentes

¿Cada cuánto tiempo hacer retrospectiva?

Cada sprint. La cadencia regular es lo que más pesa en el seguimiento: los equipos que hacen retro siempre completan cerca de tres de cada cuatro acciones, contra cerca de la mitad de los que lo hacen de vez en cuando. Sin la retrospectiva siguiente, nadie revisa, y sin revisión la acción muere.

¿Cuánto tiempo debería durar una retrospectiva?

El Scrum Guide limita la retrospectiva a un máximo de 3 horas para un sprint de un mes — el techo, no la meta. La mayoría de los equipos con sprint de dos semanas la corre en 45 a 90 minutos. Si el equipo no tiene tiempo, acórtala a 30 minutos con un único foco en lugar de cancelarla.

¿Qué hacer cuando el equipo siempre trae los mismos problemas?

Dos cosas distintas, que parecen la misma. Si la acción existe pero nunca fue asumida, el problema es de responsable y cadencia: limita a una acción, con fecha de revisión, y verifícala al inicio de la próxima retro. Si el problema vuelve porque está fuera del alcance del equipo — presupuesto, plantilla, decisión de arquitectura tomada más arriba —, volver a listarlo no va a funcionar. Escálalo a quien decide, con nombre y plazo, y mantén eso visible.

¿Cuántas acciones definir por retrospectiva?

Una a tres. Las retrospectivas que terminan con diez acciones o más completan cerca del 56% de ellas, contra cerca del 79% en las que terminan con una a tres. Si el equipo identificó diez problemas que vale la pena resolver, eso es una lista para priorizar en los próximos meses — no un compromiso para el próximo sprint.

¿Cómo registrar la retrospectiva sin que alguien anote?

Graba la reunión con IA — bot en la llamada o audio del ambiente — y recibe resumen, checklist de acciones, hoja de ruta y mapa mental automáticamente. El registro deja de depender de quien tiene el cuaderno abierto, y cada retrospectiva pasa a ser un documento que se puede buscar en lugar de una página que nadie reabre.

Deja de anotar. Empieza a entender.

Una retrospectiva que termina en dos acciones con responsable y fecha vale más que una que termina en doce buenas intenciones. Y un historial que se puede buscar de retrospectivas vale más que una carpeta de actas que nadie abre: la mejora continua solo sucede cuando el equipo logra ver lo que ya se discutió — y exigir lo que se decidió.

Graba la retro, deja que la IA estructure, empieza la siguiente por lo que quedó acordado. Es un ciclo simple, y es la única forma de que gire.