La Definition of Ready en Scrum

Definition of Ready en Scrum

Durante el Sprint Zero (o como quieras llamarle a la fase de planificación previa a los Sprints) el Equipo Scrum (Product Owner, Equipo de Desarrollo y Scrum Master) debe dejar definidas y por escrito un par de reglas muy importantes de cara al buen entendimiento del equipo: la Definition of Ready y la Definition of Done.

En este post hablaremos de la Definition of Ready y de cuán importante es dejarla bien redactada y visible a todos.

Comenzamos. 

Qué es la Definition of Ready Scrum (DoR)

Cuando el Equipo de Desarrollo Scrum se dispone a abordar una Historia de Usuario para su construcción debe ser cuidadoso de que ésta sea abordable y que no presente inconsistencias.

A veces el DevTeam se compromete, inocentemente, a desarrollar una Historia que no estaba lo suficientemente madura para ello.

El Product Owner no siempre tiene las Historias de Usuario lo suficientemente trabajadas y puede terminar poniendo al DevTeam en el brete de construir en base a unos pobres requisitos que suponen desarrollar sobre arenas movedizas.

Por tanto, es importante que queden convenientemente por escrito los criterios que determinan que una Historia de Usuario está preparada para ser construida. Ambas partes, DevTeam y Product Owner, deberán respetar estos criterios.

Para ello, antes de comenzar con el Sprint 1, debe quedar establecida y escrita una declaración de intenciones a la que llamaremos Definition of Ready (DoR – Definición de Preparada).

La Definition of Ready describe los criterios para toda Historia de Usuario susceptible de entrar en el próximo Sprint. Es decir, indica qué condiciones debe cumplir para poder tomarla del Product Backlog y pasar a formar parte del Sprint Backlog para que el DevTeam la construya.

Ojo, no confundas el Product Backlog con el Sprint Backlog. El Product Backlog recoge toda la funcionalidad del proyecto, incluyendo además las tareas técnicas y los bugs.

El Sprint Backlog recoge el trabajo que se abordará durante un Sprint en particular, podríamos considerarlo un subconjunto del Product Backlog para el Sprint en vuelo.

El Sprint Backlog incluye además las subtareas (las cuestiones más puramente técnicas) que habría que realizar para dar por done una historia de usuario o historia técnicas: subtareas de desarrollo backend, subtareas de desarrollo del frontend, subtareas de testing, de devops, etc.

Cuándo una historia de usuario estará ready

Básicamente, una Historia de Usuario estará lista para su desarrollo cuando cumpla con las siglas INVEST: Independiente, Negociable, Valiosa, Estimable, Corta (Short) y Testeable.

Es decir, para que una Historia de Usuario sea abordable por el DevTeam debe presentar las siguientes características:

  • Independiente: no tendrá dependencias con otras historias que pudieran impedir su desarrollo. Por tanto, si para que la funcionalidad A sea posible es necesario tener la B, entonces la historia A no es independiente.
  • Negociable: debe permitir espacio para la discusión con el Product Owner.
  • Valiosa: debe aportar valor al cliente. Cumpliendo este criterio evitas desarrollar algo inútil.
  • Estimable: puede ser estimada por el DevTeam (en tamaño relativo, en puntos de historia, etc).
  • Corta: debe poder terminarse durante el Sprint. Si te topas con una Historia más grande que eso exige al Product Owner que la subdivida en varias Historias más pequeñas.
  • Testeable: la Historia en su descripción debe contar con la información suficiente como para poder ser probada.

Una vez que tengas definida tu DoR, ponlo por escrito en tu gestor documental y también imprímelo en un papel y pégalo en alguna pared de tu sala agile. Así todos serán conscientes de dichos requisitos y nadie los olvidará.

IMPORTANTE:

El DevTeam no debería comprometerse a desarrollar ninguna historia de usuario que no cumpla con la DoR.

El Scrum Master debe velar por el cumplimiento de ello.

Ejemplo de Definition of Ready

Te muestro un ejemplo de DoR. Úsalo tal que así o adáptalo a tus necesidades de proyecto.

Lo más importante es que te quedes con la idea de redactar todos los requisitos que determinen que una Historia del Product Backlog está lista para poder abordarla en el Sprint que corresponda.

DoR – Proyecto XXX

  • Independiente. No tendrá dependencias externas que impidan que la historia sea completamente desarrollada.
  • Valiosa. La historia de usuario expresará valor de negocio.
  • Deberá estar estimada por el Equipo de Desarrollo según el método de estimación que el equipo considere.
  • Desarrollable al completo en un solo Sprint.
  • Debe ser testeable.
  • Debe estar descrita por el Product Owner de forma clara y sin ambigüedades y comprendida por el DevTeam como para ser COMPLETAMENTE desarrollada.
  • Los criterios de aceptación que describen la Historia de Usuario serán detallados, sin ambigüedades y testeables.
  • En caso de ser necesario, los criterios de rendimiento (véase Pruebas de Carga) están definidos y son testeables.
  • Historia de Usuario aprobada por Arquitectura Funcional.
  • Historia de Usuario aprobada por el Usuario.

Reflexión final

La DoR, lejos de ser un formalismo absurdo, es un contrato entre el Product Owner y el Equipo de Desarrollo. Sirve, sobre todo, para dejar constancia de que ambas partes se comprometen a cumplir con su parte y no invadirán las competencias del otro.

Muchos conflictos entre Product Owners y DevTeams han sido provocados por desacuerdos sobre qué puede admitir el DevTeam y qué no. Por tanto, una sana forma de evitarlo es dejar estos criterios bien redactados y a la vista de todos. Así nadie se llevará a engaños.

Por tanto, tómate en serio la redacción de este pequeño documento y no comiences ningún Sprint sin él. Te ahorrarás muchos quebraderos de cabeza.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

2 comentarios en “<b>La Definition of Ready en Scrum</b>”

Deja un comentario