Nuestra DoR actual

¿Cómo es hoy nuestra Definición de Listo?

Decimos que una historia está lista cuando tiene criterios de aceptación, pero no creo que todos estemos de acuerdo en qué son unos criterios de aceptación 'buenos'.
Nuestra DoR incluye: historia de usuario redactada, criterios de aceptación definidos, historia estimada en puntos y dependencias identificadas.
Sinceramente, no tengo claro que tengamos una DoR formal. Cogemos lo que esté arriba del todo en el backlog.
Cuando funciona

¿Qué va bien cuando las historias cumplen nuestra Definición de Listo?

Cuando las historias están bien dimensionadas y tienen criterios de aceptación claros, la planificación del sprint es muchísimo más rápida. Terminamos en menos de una hora.
Noto que tenemos muchos menos bloqueos a mitad de sprint cuando las dependencias se señalan desde el principio durante el refinamiento.
El equipo se siente más seguro al comprometerse con las historias cuando todos hemos podido hacer preguntas antes de que empiece el sprint.
Cuando falla

¿Qué problemas surgen cuando las historias no están realmente listas?

El sprint pasado metimos una historia sin criterios de aceptación y acabó en tres días de idas y venidas con el PO.
Las historias sin un alcance claro suelen darse por 'terminadas' de forma distinta según quién las desarrolle, y luego QA encuentra incoherencias.
No paramos de descubrir dependencias a mitad de sprint que nos bloquean durante días. Esto debería detectarse en el refinamiento.
Mejorar nuestra DoR

¿Qué cambios deberíamos hacer para reforzar nuestra Definición de Listo?

Deberíamos añadir una checklist a la plantilla de tickets de Jira para que no se escape nada antes de marcar una historia como lista.
Me gustaría que acordáramos que ninguna historia entre en un sprint sin al menos una sesión de refinamiento con todo el equipo presente.
Necesitamos una regla clara: si una historia no tiene criterios de aceptación 48 horas antes de la planificación, no se planifica.

¿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.

Preguntas frecuentes

¿Qué es una retrospectiva de Definición de Listo?
Es una retrospectiva que revisa los criterios de entrada de tu equipo para los elementos del backlog. El tablero recoge vuestra DoR actual, qué funciona cuando las historias la cumplen, qué falla cuando no la cumplen y qué cambiar.
¿Qué diferencia hay entre la Definición de Listo y la Definición de Terminado?
La Definición de Listo establece los criterios de entrada que un elemento del backlog debe cumplir antes de entrar en un sprint. La Definición de Terminado establece los criterios de salida que indican cuándo el trabajo está completo. Esta retrospectiva se centra en la primera.
¿Con qué frecuencia debería un equipo hacer una retrospectiva de Definición de Listo?
Hazla después de un sprint difícil con requisitos poco claros, cuando se incorporen personas nuevas o cada pocos meses para comprobar que vuestra DoR sigue reflejando cómo trabaja el equipo.
¿La Definición de Listo forma parte de Scrum?
No. La Guía de Scrum define la Definición de Terminado, pero no la Definición de Listo, que muchos equipos Scrum añaden por su cuenta. Mantenla ligera para que no se convierta en una barrera que frene trabajo útil.
¿Cuánto dura una retrospectiva de Definición de Listo?
Entre 45 y 60 minutos para la mayoría de los equipos. Centra la conversación en los propios criterios o acabará convirtiéndose en una sesión de refinamiento.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva