¿Qué es una retrospectiva de línea de tiempo?
En una retrospectiva de línea de tiempo, el equipo reconstruye la historia de un trabajo largo, como un proyecto, un trimestre o un año, colocando en orden los eventos que lo marcaron. La actividad procede de la comunidad de retrospectivas ágiles. Esther Derby y Diana Larsen la describen como un ejercicio de recopilación de datos en su libro Agile Retrospectives: Making Good Teams Great, y se basa en el trabajo anterior de Norm Kerth sobre retrospectivas de proyecto. Cada persona añade los eventos que recuerda, les pone una fecha aproximada y explica cómo se sintió en ese momento. Lo más útil es la línea del estado de ánimo. Si colocas los momentos altos y bajos del equipo junto a los eventos que los provocaron, puedes ver cómo subió y bajó la energía a lo largo del proyecto: el lanzamiento que animó a todos, la reorganización que hundió la moral durante un mes, el cambio de alcance de última hora que nadie vio venir. Aparecen patrones que se te escaparían mirando sprint a sprint, y quienes se incorporaron a mitad de camino pueden conocer las partes de la historia que se perdieron. En TeamRetro, la plantilla de retrospectiva de línea de tiempo tiene cuatro temas: eventos clave, momentos altos, momentos bajos y lecciones para la próxima vez. Los participantes hacen primero una lluvia de ideas individual; después, el equipo agrupa las ideas relacionadas, vota lo más importante y termina acordando acciones con responsables concretos. El formato necesita bastante historia con la que trabajar, así que resérvalo para el final de un proyecto, un trimestre o un año. Para un sprint de dos semanas no merece la pena, y te servirá mejor un formato más sencillo.
Formato de retrospectiva de línea de tiempo
Eventos clave
¿Qué pasó y, más o menos, cuándo? Un evento por idea.
Los eventos clave son los hechos de la historia: entregas, decisiones, personas que llegan o se van, incidentes, plazos y cambios de rumbo. Pide a todos que añadan un evento por idea y que empiecen cada uno con una fecha o semana aproximada ("Mediados de marzo", "Semana 6") para que el equipo pueda ordenarlos. Unos días antes de la sesión, envía un recordatorio pidiendo que revisen sus calendarios, notas de versión, tickets e historial de chat. La memoria se borra rápido y, sin esto, las últimas semanas acaparan el espacio de las primeras. Si al revelar las ideas los primeros meses se ven escasos, dilo en voz alta y da a la gente un par de minutos para completar el hueco.
Momentos altos
¿Cuándo estuvo el equipo en su mejor momento y por qué?
Los momentos altos son aquellos en los que la energía, la confianza o la moral alcanzaron su punto máximo. Pide a la gente que relacione cada uno con una fecha o un evento clave y que describa cómo se sintió, no solo lo que pasó. "Sacar la beta fue un alivio enorme después de semanas de dudas" dice más que "Salió la beta". Busca lo que tienen en común los momentos altos, como objetivos claros, buena colaboración o avances visibles, porque esas son las condiciones que vale la pena repetir en el próximo proyecto.
Momentos bajos
¿Cuándo lo pasó mal el equipo y por qué?
Los momentos bajos son aquellos en los que la energía cayó: frustración, estrés, confusión o agotamiento. Pide a la gente que les ponga fecha y diga cómo se sintió, y recuerda al grupo que el objetivo es entender lo que pasó, no buscar culpables. A algunas personas les cuesta mencionar momentos bajos delante de un responsable, así que la lluvia de ideas anónima de TeamRetro ayuda aquí. Al comentarlos, comprueba si las caídas coinciden con eventos concretos. Los bajones repetidos en torno a cambios de alcance o traspasos suelen señalar un problema de proceso que merece una acción.
Lecciones para la próxima vez
¿Qué repetiríamos o cambiaríamos en el próximo proyecto?
En las lecciones, la línea de tiempo se convierte en decisiones. Pide a la gente que mire juntos los momentos altos y bajos y proponga qué seguir haciendo y qué cambiar en el próximo proyecto. Insiste en que las propuestas sean concretas: "Acordar con el cliente un proceso de cambios en el arranque" es algo sobre lo que se puede actuar, y "Comunicarnos mejor" no lo es. Una vez agrupadas y votadas las ideas, convierte las dos o tres principales en acciones en TeamRetro, cada una con un responsable y una fecha límite, para que las lecciones lleguen al siguiente trabajo.
Cuándo utilizar este estudio retrospectivo
- Al final de un proyecto o de una entrega importante, cuando el equipo quiere repasar todo el esfuerzo antes de pasar a otra cosa.
- En revisiones trimestrales o anuales, cuando hay suficientes eventos y altibajos para mostrar una línea de ánimo clara.
- Cuando hubo personas que se incorporaron o se fueron a mitad de camino y el equipo necesita una visión compartida de lo que pasó y por qué.
- Después de una etapa de trabajo larga o difícil, para entender qué agotó la energía del equipo y qué la levantó.
- Antes de arrancar un proyecto similar, para reunir lecciones que el nuevo equipo pueda aplicar. No merece la pena hacerla para un sprint de dos semanas.
Preguntas sugeridas para romper el hielo
- Si este proyecto fuera una película, ¿qué título tendría?
- ¿Qué pequeño momento de este proyecto te hizo reír?
¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →
Ideas y consejos para su reunión retrospectiva
- Unos días antes de la sesión, envía un recordatorio pidiendo a la gente que revise sus calendarios, notas de versión, tickets e historial de chat. Sin él, el sesgo de lo reciente se impone y las últimas semanas dominan la línea de tiempo.
- Pide a todos que pongan una fecha o semana aproximada al principio de cada idea. Las ideas con fecha son mucho más fáciles de ordenar y agrupar, y hacen visibles las subidas y bajadas del ánimo del equipo.
- Anima a la gente a contar cómo se sintió en cada evento, además de lo que pasó. La parte emocional es lo que diferencia una línea de tiempo de un informe de estado del proyecto.
- Usa la lluvia de ideas anónima para que la gente pueda mencionar los momentos bajos con sinceridad, sobre todo si hay responsables o stakeholders presentes. Centra la conversación en los eventos y las condiciones, no en las personas.
- Reserva más tiempo que para una retro de sprint normal. Un proyecto largo tiene mucha historia, así que calcula entre 60 y 90 minutos y limita el tiempo de cada tema para que las lecciones no queden apretadas al final.
- Cierra con pocas acciones, cada una con un responsable y una fecha límite. Revísalas al inicio del siguiente proyecto para que las lecciones se apliquen.