Sprint retrospective y sprint review: significado, proceso y diferencias clave
Respuesta rápida
Probablemente ya conoces la retrospective como una de las ceremonias del framework Scrum. Piensa en ella como un espacio donde el equipo reflexiona sobre cómo está trabajando en conjunto. No se trata de averiguar quién es responsable de qué; es el momento de enfocarse únicamente en lo que puede mejorar.
La review tiene un propósito diferente. No está centrada en el crecimiento del equipo, sino en el incremento del producto.
Ambas prácticas son una buena forma de que los equipos Agile mejoren continuamente sus procesos. Ayudan a garantizar que todos entren al próximo sprint trabajando de manera más eficiente.
Qué es una sprint retrospective
Esta ceremonia ágil ocurre cada vez que termina un sprint y sirve para que el equipo determine qué logró hacer. Su objetivo principal es garantizar que el próximo sprint sea mejor, más fluido y sin eventos inesperados.
A diferencia de lo que puedes pensar, esta reunión no sirve para señalar culpables. De hecho, es todo lo contrario, ya que señalar culpables no aportará nada bueno al proyecto ni al equipo. El objetivo es lograr una mejora continua.
Realizar retrospectives de forma consistente es lo que las hace efectivas. Una herramienta de gestión de proyectos como Flowlu puede ayudarte a mantener todo en un solo lugar — desde el seguimiento de prioridades hasta la gestión de tu próximo sprint. También cuenta con un creador de plantillas de retrospective donde puedes probar una plantilla prediseñada para llevar a cabo una reunión exitosa.
Los participantes
#1: Scrum master
Es la persona responsable de la reunión y de mantenerla enfocada en la mejora. En muchos equipos, este rol también se conoce como facilitador.
#2: Los desarrolladores
Estos son los participantes principales. Son quienes necesitarán compartir sus experiencias sobre lo que les ayudó a tener éxito y lo que los frenó.
#3: El product owner
Es la persona responsable de indicar cómo fue la colaboración y de aclarar los requisitos.
El resultado esperado
Una reunión de retrospective tiene un objetivo: cuando termina, sales con una lista de elementos de acción que deben mejorarse en la próxima iteración. Lo último que todos quieren es que esa lista sea vaga. El resultado siempre debe ser accionable.
Por ejemplo, en lugar de algo como "Hablar más sobre diseño," debería decir algo más cercano a "El product owner debe agregar un enlace a todos los materiales antes de la fase de planificación." (Responsable: Peter).
Sprint review vs retrospective
Aquí hay una comparación rápida:
|
Review |
Retrospective |
|
| Propósito |
Enfocada en el "Qué". Verifica el entregable y recopila feedback de las partes interesadas. |
Centrada en el "Cómo". Analiza cómo transcurrió la iteración en términos de herramientas, procesos, relaciones y personas, y elabora un plan de mejora continua. |
| Público |
Además del scrum master, los desarrolladores y el product owner, los participantes también incluyen a la dirección, clientes, partes interesadas y usuarios. |
Solo los miembros principales participan en esta ceremonia. |
| Agenda |
El product owner comienza revisando lo que se hizo, mientras los desarrolladores demuestran el producto funcional. Se invita a las partes interesadas a dar feedback, que el product owner toma en cuenta para el próximo ciclo. |
Todos se reúnen y se le pregunta a cada miembro qué salió bien y qué no. Esto le proporciona al grupo material para debatir y decidir mejoras para el próximo ciclo. |
| Artefactos |
Product backlog → product owner. Sprint backlog → desarrolladores. Incremento → equipo Scrum. |
Una lista de nuevas prioridades para iniciar el próximo ciclo. |
| Resultados |
Un nuevo conjunto de prioridades para el próximo ciclo, haciéndolo más rápido y fluido. |
Una lista de nuevos elementos accionables para iniciar el próximo ciclo. |
| Ejemplos |
Desarrollo de una funcionalidad de checkout para invitados. Durante el proceso de sprint review, los desarrolladores muestran la pantalla y una demo. Una parte interesada indica que necesita una casilla de opt-in para newsletter antes de que el usuario realice el pago. Antes de que termine la reunión, el product owner escribe una nueva user story y la añade como prioridad al backlog. |
La reunión tiene lugar más tarde esa tarde. Un desarrollador menciona que, aunque la demo salió bien, un problema con la documentación de la API le costó al grupo dos días extra. Otro desarrollador coincide y añade que no pudo ayudar en ese momento porque estaba ocupado en otra tarea. Todos trabajan entonces juntos en un nuevo plan de acción basado en estos hallazgos. |
Cómo llevar a cabo una reunión de retrospective eficaz
Paso #1: Establece el contexto
Piensa en este paso como un calentamiento — un rompehielos antes de la reunión en sí. De 5 a 10 minutos suele ser suficiente para evaluar el nivel de energía de todos los participantes. Puedes preguntarles directamente o usar una encuesta anónima. Algunos también utilizan juegos divertidos de retrospective.
Paso #2: Recopila feedback
Idealmente, este paso toma entre 10 y 15 minutos. Úsalo para recopilar feedback de todos. Todavía no debe haber ningún análisis.
Puedes usar notas adhesivas si prefieres algo físico, o una pizarra digital como Miro. Asegúrate de que todos usen el mismo formato para compartir su feedback como parte de la agenda de la reunión.
Por ejemplo, las 4 Ls ("me gustó," "aprendí," "faltó," y "deseé") o el clásico "qué salió bien" y "qué salió mal".
Paso #3: Agrupa los insights
Es cuando comienzas a identificar patrones. Este paso debe tomar alrededor de 15 a 20 minutos. El objetivo es detectar tendencias en todas las notas adhesivas recopiladas. Agrupa ideas similares y deja que los participantes voten para destacar las 3 a 5 más urgentes.
Paso #4: Define las acciones
Aquí es donde ocurre el brainstorming. Ten en cuenta que debes salir con una lista de elementos accionables. No notas genéricas, sino soluciones específicas a los problemas discutidos.
Paso #5: Asigna responsables
El objetivo aquí es hacer que alguien sea responsable para que nada se pierda. 5 minutos deberían ser más que suficientes para encontrar un voluntario para cada elemento.
Recuérdales a todos que la persona a cargo no es responsable de hacer todo el trabajo — es responsable de asegurarse de que el elemento no se olvide. Su función es darle seguimiento, impulsarlo y reportar en la próxima retrospective.
Termina la reunión con una lista escrita de todas las acciones y agrégalas a tu herramienta de gestión de proyectos.
Preguntas, errores y plantillas
Ejemplos de preguntas para sprint retrospective
Algunos equipos simplemente no responden bien a preguntas como "¿Qué salió bien?"
Entonces, si tus colegas son así, hay otras formas de iniciar una reunión de retrospective.
Intenta hacer otros tipos de preguntas.
-
Si quieres romper el hielo
Comienza con algo como "¿Viste a alguien lograr algo esta semana? ¿Qué fue?"
-
Si necesitas desbloquear preguntas relacionadas con procesos
Puedes preguntar: "¿Puedes contarme cuál fue la tarea más repetitiva que tuviste que hacer en este sprint?"
-
Si quieres descubrir riesgos que podrías enfrentar en el futuro
Preguntas como "¿Tomaste un atajo en este sprint que tendrás que corregir después?" pueden ser una buena idea.
Errores comunes
#1: Ninguna acción real
El principal objetivo de las reuniones de retrospective es reunir suficiente conocimiento para elaborar una lista clara de mejoras. Por lo tanto, no pases toda la reunión enfocado en el problema; la gran mayoría del tiempo debe dedicarse a buscar y analizar soluciones.
#2: Señalar culpables
Como mencionamos anteriormente, estas reuniones están pensadas para ayudar a los equipos a seguir mejorando la salud del equipo. No están destinadas a rastrear quién hizo qué, cuándo o cuánto tiempo tomó. Por lo tanto, reformula las preguntas para apuntar a los problemas y no a los individuos.
#3: Demasiados elementos accionables
Si bien el objetivo es claramente la mejora continua, no querrás terminar la reunión con una lista de 10 o 20 elementos. Asegúrate de salir con no más de 3 puntos de seguimiento.
#4: No utilizar los elementos accionables
Para asegurarte de que no se olviden, integra estas mejoras en tu flujo de trabajo de inmediato.
Tu checklist de seguimiento
Lo más importante que debes hacer después de una scrum retrospective es agregar tus nuevas prioridades a tu software de gestión de proyectos, para que no se olviden.
Sigue el checklist a continuación:
#1: Antes de comenzar
- Confirma si las prioridades de la reunión anterior fueron completadas y si resolvieron el problema.
- Usa métricas como defectos escapados, gráficos de burndown y velocidad para determinar qué ocurrió.
- Ten el tablero listo para usar (físico o digital).
#2: Durante la reunión
- Mantén todas las discusiones constructivas.
- Asigna a cada elemento accionable un responsable y una fecha límite.
#3: Después del cierre
- Agrega los elementos de acción a Flowlu (o a la herramienta de gestión de proyectos de tu preferencia).
- Revisa los elementos de acción en cada daily standup.
Flowlu es una de las opciones más completas para esto. Cuenta con un entorno Agile diseñado específicamente para que puedas iniciar sprints, programar retrospectives recurrentes y gestionar todo en un solo lugar. Después de la reunión, agrega los próximos pasos, clasifica cada uno por tipo — tarea, bug o historia — establece una prioridad y hazlos visibles para todo el equipo. Si el trabajo abarca más de un sprint, agrúpalo bajo un epic y vincula los issues individuales a él a medida que avanzas.
A medida que el sprint avanza, Flowlu genera automáticamente un gráfico de burndown. Esto te ofrece una visión rápida y clara de si el equipo está en camino de completar el objetivo del sprint dentro del plazo establecido.
Ejecuta sprints de forma eficaz
Si bien una scrum retrospective es muy importante, no puedes tratarla como una simple lista de ideas anotadas y dejadas en el olvido. El objetivo es tomar lo que ocurrió en el sprint anterior y usarlo para mejorar el siguiente. Si no lo ejecutas, simplemente estás perdiendo el tiempo.
Una de las cosas más importantes que debes recordar sobre estas reuniones es que tienen un tiempo limitado. No conviertas algo que puede hacerse en una hora en una reunión de 3 o 4 horas. No será nada productivo.
Es una ceremonia ágil en Scrum. Su objetivo principal es entender qué hizo bien el equipo y qué salió mal para mejorar en el próximo sprint.
Es conducida por el scrum master y los demás participantes incluyen a los desarrolladores y el product owner.
Aunque existen diferentes enfoques según tu equipo, las preguntas más habituales que los colaboradores deberán responder incluyen:
- ¿Qué salió bien?
- ¿Qué salió mal?
- ¿Qué podemos hacer en el futuro?
En la mayoría de los casos (para una iteración de 2 semanas), estas reuniones duran alrededor de 1,5 horas. Sin embargo, el tiempo depende del número de días del sprint.
Por ejemplo, si el sprint duró 3 semanas, la reunión puede durar hasta 2,25 horas. En caso de que el sprint haya durado solo 1 semana, la retrospective debería tomar 45 minutos como máximo.
