Esta reunión se realiza después de la reunión de demo con el cliente y tiene una duración de tres horas para sprints de un mes. Se trata de una reunión en la que queremos que el equipo Scrum se revise a si mismo y dé feedback de cómo han ido las cosas, por qué no pudieron conseguirse todos los objetivos del sprint, si fue así, y qué podemos hacer para mejorar en el siguiente sprint.

A esta reunión asistirán el Dueño del Producto, el Scrum Master y el equipo de desarrollo. El Scrum Master como siempre se encargará de que la reunión tenga lugar. de que se mantenga dentro de los tiempos máximos definidos y que se traten al menos los siguientes aspectos en la reunión:

• Qué cosas han funcionado bien
• Qué cosas no han funcionado tan bien y evitaron que pudiéramos demostrar al cliente todo lo que se esperaba de este sprint que acaba de terminar
• Qué problemas han impedido o pueden impedir que no consigamos nuestra meta del sprint y que el cliente por tanto no obtenga lo esperado. El Scrum Master se encargará de anotarlas para luego ponerse a resolverlas.

De esta reunión de retrospectiva debería salir un plan, ordenado por prioridad, con las distintas mejoras que podrían implementarse para evitar los problemas detectados.

Existen diversas causas por las que las reuniones de retrospectiva resultan poco provechosas o no todo lo útiles que deberían:

Las reuniones son aburridas y monótonas

La gente puede perder la confianza en las retrospectivas y verlas como una perdida de tiempo si no se toma ninguna acción después de analizados los problemas que se están teniendo. Se están identificando los problemas y se están declarando pero no se hace nada al respecto o tarda mucho en tomarse consciencia de lo que están suponiendo. Debemos tomar buena nota de cada una de las mejoras propuestas y de los impedimentos que están impidiendo avanzar y hacer algo con ellos. Tener una reunión de retrospectiva para luego no tomar ninguna medida va a hacer que se pierda la fe en estas reuniones.

La gente tiene miedo de las retrospectivas

Miembros del equipo de desarrollo pueden sentirse temerosos de comentar los problemas reales que están viendo y sólo dicen vaguedades o pequeños impedimentos pero no la causa que ellos ven como la más importante y por la que no se consiguen los objetivos del sprint. Quizás por temor a herir los sentimientos del Scrum Master o del Dueño del Producto si no están haciendo bien su trabajo, quizás por no molestar al analista que no recoge bien los requerimientos, quizás por temor a ser represaliados si son demasiado directos con lo que se piensa.