¿Qué es una retrospectiva de Definición de Listo?
Un sprint va mejor cuando el trabajo que incluye ya estaba listo antes de empezar la planificación. La Definición de Listo (DoR, del inglés Definition of Ready) es la lista de criterios de entrada que un elemento del backlog debe cumplir antes de incorporarse a un sprint, como los criterios de aceptación, una estimación y las dependencias conocidas. La retrospectiva de Definición de Listo sirve para comprobar si esa lista cumple su función. El tablero tiene cuatro columnas. Nuestra DoR actual recoge cuáles son hoy los criterios en la práctica, que a menudo resultan ser distintos para cada persona. Cuando funciona reúne ejemplos de historias listas que avanzaron sin problemas. Cuando falla trata lo que ocurrió cuando entró en un sprint trabajo que no estaba listo. Mejorar nuestra DoR es donde acordáis los cambios. Úsala cuando la planificación se alarga una y otra vez, las historias se atascan a mitad de sprint o nadie ha revisado vuestra DoR en meses. Sirve tanto para equipos Scrum como Kanban. En TeamRetro se pueden añadir ideas de forma anónima, así que los problemas del refinamiento salen a la luz aunque resulte incómodo plantearlos.
Formato de retrospectiva de Definición de Listo
Nuestra DoR actual
¿Cómo es hoy nuestra Definición de Listo?
Pide a todos que escriban cuáles creen que son los criterios actuales. Muchos equipos tienen una DoR informal o no escrita, y las diferencias entre las respuestas de cada persona te indican por dónde empezar.
Cuando funciona
¿Qué va bien cuando las historias cumplen nuestra Definición de Listo?
Busca sprints o historias concretas en los que estar listos marcó la diferencia, como una planificación corta o una historia terminada sin tener que perseguir a nadie. Estos ejemplos muestran al equipo por qué merece la pena mantener la DoR.
Cuando falla
¿Qué problemas surgen cuando las historias no están realmente listas?
Esta columna suele ser la que más dice. Pide historias concretas que entraron en un sprint sin cumplir la DoR y qué pasó después. Busca patrones: ¿se repiten siempre las mismas carencias o afectan siempre al mismo tipo de historias?
Mejorar nuestra DoR
¿Qué cambios deberíamos hacer para reforzar nuestra Definición de Listo?
Acordad cambios concretos, como añadir o quitar criterios, cambiar la forma de hacer el refinamiento o ajustar las herramientas. Intentad salir con 1–3 cambios para probar en el próximo sprint.
Cuándo utilizar este estudio retrospectivo
- Tu equipo sufre continuamente bloqueos a mitad de sprint, crecimiento descontrolado del alcance o historias que no se pueden terminar en el sprint, lo que a menudo indica que el trabajo no estaba listo al planificarlo.
- La planificación del sprint se alarga o resulta caótica porque el backlog no se refinó antes de que el equipo se comprometiera.
- Estás incorporando a personas nuevas al equipo y quieres dejar por escrito qué significa 'listo' para vosotros.
- Tu equipo tiene una Definición de Listo, pero hace tiempo que no la revisa y puede que ya no encaje con vuestra forma de trabajar actual.
- Después de un sprint difícil en el que los requisitos poco claros o la falta de información provocaron retrasos o retrabajo.
Preguntas sugeridas para romper el hielo
- Si tu backlog fuera una cocina, ¿sería una despensa bien surtida y ordenada o una nevera caótica llena de sobras misteriosas? ¿Por qué?
- ¿Qué es eso que te gustaría saber al empezar una tarea y que siempre acabas descubriendo a mitad de camino?
¿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
- Comparte vuestra DoR actual antes de la sesión para que la gente llegue con ejemplos reales.
- Habla de carencias del proceso, no de errores individuales, para que la gente pueda contar qué salió mal sin buscar culpables.
- Limita el tiempo de cada columna. Las conversaciones sobre la DoR derivan fácilmente en refinar historias concretas, así que centra la retro en los propios criterios.
- Acordad 1–3 cambios por sesión. Una DoR que intenta abarcarlo todo se vuelve demasiado larga para cumplirla.
- Implica a todo el equipo, no solo al Scrum Master o al Product Owner. Desarrollo, QA y diseño sufren de forma distinta las historias que no están listas.
- Comprueba en la siguiente retrospectiva si los cambios han facilitado la planificación y la entrega.