Saltar al contenido
Be Agile My Friend

Cómo hacer el Definition of Ready (DoR)

DoR

Cuando empezamos a aplicar una metodología ágil, una de las primeras cosas que hay que hacer es aclarar cuando una tarea está preparada para ser incluida en el sprint. Para ello debe cumplir con lo que se llama el Definition of Ready (DoR), o lo que es lo mismo, una serie de requisitos que debe cumplir.

Si las tareas que hay en el backlog no cumplen con los requisitos definidos en el DoR, no deben incluirse dentro del Sprint Backlog.

La tarea del Scrum Master es revisar si los acuerdos del DoR se cumplen para cada tarea que se incluye priorizada en el Sprint Planning, como susceptible de ser abordada en el Sprint.

Si la tarea cumple todos los requisitos, podrá ser abordada dentro del Sprint.

¿Puede una tarea que no cumple el Definition of Ready ser incluida en el Sprint Backlog?

En un entorno ágil, debemos tratar de cumplir con los acuerdos de trabajo, pero como estamos tratando de adaptarnos al cambio puede ser que en ciertas ocasiones, debamos permitir que una tarea que no cumple con todos los requisitos del DoR pueda entrar en el Backlog.

Por ejemplo, si uno de los requisitos de nuestro DoR es que es necesario que un usuario de negocio tenga disponibilidad para realizar la verificación de una tarea. Se contacta con el usuario de negocio y nos dice que no estará disponible en el sprint pero la resolución de esa tarea supone la resolución de una incidencia que de no resolverse puede afectar a los resultados de negocio. En ese caso incluiríamos esa tarea en el Sprint, previo acuerdo con la persona de negocio que la validación y verificación será realizada por el equipo Scrum.

¿Cada cuanto deben revisarse los acuerdos del Definition of Ready?

Cuando empezamos a trabajar con el equipo Scrum comenzamos con una definición del DoR que debe ir adaptándose en los primeros 10 sprints para tener un DoR con unos acuerdos consolidados. Una vez maduros, únicamente deberían adaptarse si hay cambios técnicos u organizativos por lo que se vean afectados y que requieran de una actualización de los mismos para adaptarse a la nueva situación.

También puede ser necesario adaptarlos si tras el resultado de una retrospectiva el equipo acuerda que es necesario hacer un cambio en los mismos para que el funcionamiento de equipo se adapte a la nueva situación.

¿Que criterios clave se deben tener en cuenta en la definición del Definition of Ready?

Los principales criterios claves a tener en cuenta son los siguientes:

  • La tarea pueda ser abordada y terminada en el sprint en el que se incluya sin ninguna dependencia o bloqueo inicial que impida que esto ocurra.
  • Las dependencias  de esa tarea deben quedar resueltas antes de empezar a trabajar con ella, tanto si la dependencia es externa, como si depende de otras tareas que se abordan en el mismo sprint.
  • Los puntos de historia por tarea única no deben superar la complejidad máxima a abordar por un desarrollador en el periodo del sprint. En el caso de que esto ocurra, la tarea deberá dividirse en tareas más pequeñas en cuanto a complejas y que sigan aportando valor.

Ejemplos de criterios en la definición del Definition of Ready

Como referencia podríamos tener en cuenta los criterios mas comunes que se utilizan en la definición del DoR, aunque habrá que tener en cuenta la particularización al desarrollo de trabajo en el equipo ágil donde se va a tener en cuenta.

  • La tarea debe tener una estimación de complejidad (puntos de historia).
  • El detalle funcional, detalle técnico y los casos de prueba de cada tarea deben ser claros para que sean entendibles por cualquier miembro del equipo.
  • La tarea no debe tener bloqueos que impidan su ejecución.
  • Las dependencias deben estar resueltas.
  • La tarea debe poder validarse y verificarse dentro del Sprint.

 Consecuencias de no tener en cuenta el Definition of Ready

Si incluimos tareas en el Sprint que no cumplen con el DoR podemos encontrarnos con cosas como:

  • Tiempo empleado en la tarea tirado a la basura porque no puede terminarse la tarea dentro del sprint.
  • Desorientación en el equipo a la hora de abordar tareas que no cumplen los requisitos iniciales del DoR.
  • Desconfianza en los clientes al poner en riesgo el valor incremental del producto al finalizar el sprint.

 

¿Te ha gustado el post?

Valóranos!

Puntuación media / 5. Recuento:

¿Nos ayudas a compartir?

Elige la red social que prefieras!