Descarga la plantilla de retrospectiva
Imprímela para la pared o edítala en la herramienta que ya usas. Gratis, sin dejar tu correo y sin registrarte. Los archivos están en inglés.
Una retrospectiva ágil es una reunión breve y periódica en la que un equipo repasa un periodo de trabajo, normalmente un sprint, y acuerda qué cambiar en cómo trabaja. La planificación trata de qué va a construir el equipo; la retrospectiva, de la forma en que lo construye. El resultado no es una lista de quejas, sino uno o dos cambios concretos que el equipo probará antes de la siguiente retrospectiva.
Las retrospectivas vienen directamente del Manifiesto Ágil de 2001, cuyo último principio pide a los equipos que reflexionen a intervalos regulares sobre cómo ser más eficaces y que ajusten su comportamiento en consecuencia. En Scrum, la Sprint Retrospective es el evento que cierra cada sprint.
Esta guía recorre las cinco fases de una buena retrospectiva, compara los formatos más habituales e incluye un ejemplo práctico en el que un equipo pasa de los pósits a un único cambio comprometido, con su responsable.
En resumen
Una retrospectiva ha cumplido su función cuando el equipo sale con un cambio concreto, un responsable y una forma de comprobar si ha funcionado. Todo lo demás en la reunión sirve para encontrar ese cambio.
La Prime Directive
La mayoría de las retrospectivas empiezan recordando la Retrospective Prime Directive (la «directiva primaria»), que Norm Kerth formuló en Project Retrospectives (2001). En pocas palabras: descubramos lo que descubramos, damos por hecho que cada persona hizo el mejor trabajo posible con lo que sabía, sus capacidades, los recursos disponibles y la situación del momento.
No está ahí por cortesía. Un equipo que espera que le busquen culpables dará un feedback seguro y genérico y esconderá la causa real. Sacar la culpa de la mesa es lo que permite que alguien diga en voz alta «no sabía que la especificación había cambiado», y esa frase suele ser el momento en que empieza la parte útil de la reunión.
Las cinco fases de una retrospectiva
El libro Agile Retrospectives, de Esther Derby y Diana Larsen, describe cinco fases que sigue casi cualquier buena retrospectiva, sea cual sea su formato:
| Fase | Para qué sirve | Tiempo habitual en una retro de 45 minutos |
|---|---|---|
| 1. Preparar el terreno | Recordar el objetivo y la Prime Directive; que todos hablen pronto | 5 minutos |
| 2. Recoger datos | Reunir lo que pasó: hechos, acontecimientos y cómo se sintió la gente | 10 minutos |
| 3. Generar ideas | Agrupar los datos, elegir el tema más importante y encontrar su causa raíz | 15 minutos |
| 4. Decidir qué hacer | Elegir uno o dos cambios, cada uno con un responsable | 10 minutos |
| 5. Cerrar | Confirmar los compromisos y valorar cómo ha ido la reunión | 5 minutos |
La fase que más se salta es la tercera. Pasar directamente de «estos son nuestros pósits» a «estas son nuestras acciones» da lugar a acciones que tratan síntomas.
Formatos habituales de retrospectiva
El formato es el conjunto de preguntas que usas en la fase 2. Ir cambiando de formato evita que una retrospectiva periódica se vuelva rutinaria.
| Formato | Preguntas | Ideal para |
|---|---|---|
| Start, Stop, Continue | ¿Qué deberíamos empezar a hacer, dejar de hacer y seguir haciendo? | Equipos nuevos; retros rápidas |
| Starfish (estrella de mar) | Seguir haciendo, hacer más, hacer menos, dejar de hacer, empezar a hacer | Equipos que quieren más matices que «bien» y «mal» |
| Mad, Sad, Glad | ¿Qué te frustró, te decepcionó o te alegró? | Sprints que fueron duros a nivel emocional |
| 4Ls | Lo que nos gustó, lo que aprendimos, lo que faltó, lo que echamos de menos | Final de un proyecto o de un trimestre |
| Velero | Viento (lo que nos ayudó), anclas (lo que nos frenó), rocas (riesgos por delante) | Equipos que se adentran en una etapa arriesgada |
| Línea temporal | Situar los hechos clave del sprint y marcar los altos y bajos | Revisiones tras un incidente o un lanzamiento |
El Starfish, que suele atribuirse a Patrick Kua, es el formato que usa nuestra plantilla de retrospectiva gratis. Sus cinco categorías dejan sitio para «esto funciona, pero nos pasamos», un matiz que se pierde con una simple división entre bueno y malo.
Un ejemplo práctico de retrospectiva
Esta es una retrospectiva de 45 minutos de un equipo de producto ficticio de siete personas. Su sprint de dos semanas terminó con una función de exportación para clientes entregada con tres días de retraso.
Fase 1: Preparar el terreno (5 minutos)
El facilitador recuerda la Prime Directive y plantea el objetivo: «Entregamos la exportación tres días tarde. Vamos a averiguar por qué y a acordar un cambio para el próximo sprint». Cada persona resume el sprint en una palabra. Dos dicen «con prisas».
Fase 2: Recoger datos (10 minutos)
El equipo traza una línea temporal rápida del sprint y después escribe notas Starfish en silencio durante cinco minutos, para que no sea la voz más alta la que marque la agenda.
| Seguir haciendo | Hacer más | Hacer menos | Dejar de hacer | Empezar a hacer |
|---|---|---|---|---|
| Daily stand-ups de menos de 15 minutos | Pairing en las historias complicadas | Revisiones de diseño improvisadas por chat | Cambiar los criterios de aceptación a mitad de sprint | Enseñar los diseños al cliente antes del sprint |
| Escribir los tests antes del merge | Demos al cliente | Reuniones de seguimiento que podrían ser un mensaje | Empezar historias sin el mockup definitivo |
Fase 3: Generar ideas (15 minutos)
El equipo agrupa las notas y vota. El grupo más grande, con diferencia, tiene que ver con requisitos que cambiaron después de empezar el sprint. El equipo le aplica los 5 porqués:
- ¿Por qué se entregó tarde la exportación? En las pruebas se vio que no hacía lo que el cliente esperaba.
- ¿Por qué? Los criterios de aceptación cambiaron el sexto día del sprint.
- ¿Por qué? La responsable de operaciones del cliente vio el diseño por primera vez el quinto día.
- ¿Por qué? Los diseños se revisan internamente, pero no se enseñan al cliente antes de que una historia entre en el sprint.
- ¿Por qué? Nadie es responsable de la validación del cliente. Producto daba por hecho que se encargaba la gestión de cuentas, y la gestión de cuentas, que se encargaba producto.
La causa raíz no es «la comunicación». Es un paso del proceso sin responsable.
Fase 4: Decidir qué hacer (10 minutos)
Alguien propone «comunicarnos mejor con el cliente». El facilitador lo frena: eso es un deseo, no un cambio. En su lugar, el equipo acuerda un experimento:
- Cambio: durante los dos próximos sprints, cualquier historia con un cambio visible para el cliente necesita un mockup revisado por el cliente antes de entrar en el sprint.
- Responsable: la product manager.
- Cómo lo sabremos: contaremos las historias cuyos criterios de aceptación cambian una vez empezado el sprint. En el último sprint fueron tres.
El resto de notas va a una lista para retomarlas más adelante. El equipo se compromete con un cambio, no con siete.
Fase 5: Cerrar (5 minutos)
El facilitador repasa en voz alta el experimento y su responsable, y cada persona puntúa la retrospectiva del uno al cinco. La próxima retrospectiva empezará revisando ese recuento.
Por qué fracasa una retrospectiva
- Ninguna acción, o demasiadas. Una lista de diez mejoras es una lista de la que nadie se hace cargo. Elige una o dos.
- Acciones que son deseos. «Comunicarnos mejor» no se puede hacer el lunes. «El cliente valida los mockups antes del sprint», sí.
- No revisar nunca la acción de la vez anterior. Si la siguiente retrospectiva no empieza repasando el último cambio, el equipo aprende que los compromisos son opcionales.
- Buscar culpables. En cuanto se señala a una persona, todos los demás empiezan a medir lo que dicen.
- Siempre el mismo formato. Cambia las preguntas para que el equipo no dé las mismas respuestas en piloto automático.
Saltarse las retrospectivas por completo tiene su propio coste, del que hablamos en el coste de la deuda de procesos.
Retrospectiva vs. sprint review vs. post-mortem
Se confunden porque las tres miran hacia atrás:
- Sprint review: el equipo enseña a las partes interesadas qué ha construido y recoge feedback sobre el producto.
- Retrospectiva: el equipo analiza cómo ha trabajado y cambia su proceso. Las partes interesadas no suelen estar en la sala.
- Post-mortem: una revisión puntual de un incidente o un fallo concreto. A menudo usa las mismas fases, con una línea temporal en el centro.
Plantilla de retrospectiva gratis
La plantilla de retrospectiva gratis está disponible en PDF, documento de Word, libro de Excel y presentación de PowerPoint. Usa el formato Starfish, con preguntas para cada una de las cinco categorías y un registro de acciones con responsables y fechas.
Sigue aprendiendo sobre retrospectivas
- Cómo facilitar una retrospectiva de proyecto: la mentalidad del facilitador y cómo manejar una sala caldeada.
- Cómo hacer una retrospectiva de sprint en Microsoft Teams: una guía práctica de 45 minutos para equipos en remoto.
- El coste de la deuda de procesos: por qué saltarse las retrospectivas frena a los equipos.
Preguntas frecuentes
¿Cada cuánto debería hacer un equipo una retrospectiva?
Al final de cada sprint, o cada dos a cuatro semanas en los equipos que no trabajan por sprints. También es habitual hacer una después de un lanzamiento importante o de un incidente.
¿Cuánto debería durar una retrospectiva?
Unos 45 minutos para un sprint de dos semanas. La Guía de Scrum limita la Sprint Retrospective a tres horas para un sprint de un mes y señala que suele ser más corta en sprints más cortos.
¿Quién debería asistir a una retrospectiva?
Las personas que hicieron el trabajo: el equipo de entrega, incluidos el product owner y el Scrum Master en Scrum. Los gerentes y las partes interesadas suelen quedarse fuera para que todos puedan hablar con libertad.
¿Quién debería facilitar una retrospectiva?
A menudo el Scrum Master o un miembro del equipo que va rotando. Rotar ayuda, y en una retrospectiva tensa un facilitador externo puede mantener a la sala centrada en el proceso y no en las personas.
¿Cuál es el resultado de una retrospectiva?
Uno o dos cambios de proceso concretos, cada uno con un responsable y una forma de comprobar en la siguiente retrospectiva si ha funcionado.
¿Quieres ponerlo en práctica? Hazlo con tu equipo usando la plantilla de retrospectiva gratuita.
