SCRUM DoR – Definición de Preparado

Comentábamos en el artículo que dedicamos a la Definición de Hecho, que a veces se visualizan ambos como puertas que dan paso a los PBI (Product Backlog Items), bien desde el Product Backlog a ser considerados por el equipo para una valoración y posterior ejecución, bien a la entrega de los mismos y su conversión a incremento de producto.

En definitiva, podemos definir el DoR como un acuerdo de trabajo entre el equipo y el propietario del producto sobre lo que significa estar preparado. Es un criterio de entrada para planificar una historia en un sprint, una forma de que el propietario de un producto indique un PBI del Product Backlog como listo para trabajar en el sprint.

DoR versus DoD

Ambos son criterios negociados entre el equipo de desarrollo y el propietario del producto, y de alguna manera ambos “protegen” a los unos de los otros. El DoR ( Definition of Ready ) es una garantía de que el equipo recibirá los PBI en la forma y fondo correctos para poder ser valorados, entendidos y ejecutados y el DoD ( Definition of Done ) es el contrato que ha de cumplir el equipo en los PBI ejecutados para que siquiera el propietario del producto los tenga en cuenta como posible incremento del producto.

Muchos equipos utilizan el DoD para comprobar si una historia de usuario está terminada y el producto está listo para ser entregado. Pero, ¿qué pasa con las historias de usuarios que un equipo recibe del propietario de su producto? Los equipos pueden comprobar la calidad de las historias de los usuarios utilizando el DoR y así anticipar con el propietario del producto, que elementos pueden no ser aceptados en siguientes reuniones de planificación. Esta información es tremendamente útil para el propietario del producto y le ayuda enormemente a planificar las reuniones de refinamiento de requisitos.

Mientras que el DoR puede ser utilizado para múltiples artefactos y actividades (Product Backlog, Sprint Review, etc.), para los equipos nuevos prefiero empezar con un DoR para la preparación de los artículos del backlog, que introduce el concepto en la preparación de la planificación, una parte importante del flujo de trabajo.

Contenido del DoR

Como ejemplo ilustrativo de lo que debería mínimamente contener un DoR podemos usar la siguiente lista como base:

• Historia de usuario bien definida (parece de Perogrullo, pero creedme que he visto cosas que mejor no relatar).
• Identificadas las dependencias de la historia de usuario.
• Estimación burda del tamaño de la historia de usuario (o estimaciones previas si ya fue anteriormente considerada).

• UX asociada a la historia de usuario.
• Criterios de rendimiento, seguridad, arquitectura, etc.; asociados.
• Persona/s que aceptará/n la historia de usuario.
• Importancia/Peso de la historia de usuario.

Beneficios del DoR

Sinceramente es habitual el disponer en los equipos ágiles de un DoD, pero no tanto de un DoR. Nunca lo he entendido, pues los beneficios de ambos son enormes y el disponer de uno, pero no del otro genera una asimetría de responsabilidades que no es sana para el proceso y el equipo agile.

Entre los muchos beneficios de disponer de un DoR, los siguientes son un ejemplo ilustrativo:

• Medir el estado de “cómo de listo” está un PBI
• Ayudar al PO a detectar PBIs que necesitan ser refinados
• Mantener las responsabilidades dentro del equipo bien identificadas
• Reducir presión al equipo al evitar que se valoren PBIs con bajo grado de definición.
• Facilita la priorización y la gestión de los lotes asociados a cada Sprint
• Permite al PO una visión clara de lo que puede obtener para el producto en los siguientes sprints y le da margen de maniobra para afinar aquellos temas que quiera abordar y que detecte que no están suficientemente maduros.
• Y muchos, muchos otros.

Conclusión

En mi honesta opinión, tan útil es para un equipo ágil la existencia de un DoR, como la de un DoD. El uno sin el otro, dejan, por decirlo coloquialmente, el sistema cojo.

No podría decir que uno sea más importante que el otro, creo que los dos aportan enormemente y que debemos esforzarnos en que nuestros equipos ágiles hagan uso de ambos.