La Guía Scrum solo hace referencia explícita a la definición de hecho, aunque contiene una referencia más o menos indirecta a la definición de ready, cuando dice: Product Backlog items that can be “Done” by the Scrum Team within one Sprint are deemed “Ready” for selection in a Sprint Planning event. La definición de ready y la definición de hecho, por tanto, si bien son diferentes, están íntimamente ligadas. Cuando en el Sprint entran elementos del Product Backlog que podemos considerar ready, las posibilidades de que consigamos terminar estos elementos durante el Sprint aumenta. Aumenta y mucho. Get ready to get to done, que dirían lo anglosajones.

Características que ha de reunir un elemento del Product Backlog para cumplir con la definición de ready

Con carácter general, la definición de ready supone que un elemento del Product Backlog presente los siguientes rasgos.

1/ Sea lo suficientemente “pequeño”. Como indica la Guía Scrum, el elemento del Product Backlog (por ejemplo, la historia de usuario de que se trate) ha de ser lo suficientemente pequeño como para poder ser terminado en un Sprint. Si el equipo piensa que necesitará varios Sprints para completarlo, habrá de descomponerlo en varios (haciendo uso del llamado slicing).

2/ Haya sido estimado. Debemos tener una idea del esfuerzo asociado a tal elemento y que, junto al resto, nos dé una idea de la capacidad que asumimos para el Sprint. Hay equipos que “a ojo”, sin necesidad de hacer una estimación numérica, ya saben cuántos elementos del Product Backlog pueden hacer en un Sprint. Esto sucede con equipos experimentados que tienen un conocimiento profundo sobre el producto y la tecnología. También vale estimar de esta manera, claro que sí.

3/ Sea comprendido por el Equipo de Desarrollo. Lo que de verdad importa es que hayamos hablado sobre el elemento del Product Backlog y sus implicaciones. Que hayamos logrado un entendimiento compartido. Si la primera vez que el Equipo de Desarrollo sabe de un “ticket” es durante la Sprint Planning, algo estamos haciendo mal.

4/ Contenga justo con el nivel de detalle suficiente. El elemento del Product Backlog debe incluir criterios de aceptación que confirmen el comportamiento deseado por el cliente o usuario. ¿Cuántos criterios de aceptación debemos incluir? Mientras añadan claridad, bien están. En cuanto dejen de aportar, mejor parar. El exceso de detalle es despilfarro, y la escasez de detalle puede significar que 3/ no se cumple. Algunos equipos pueden decidir que ese detalle debe incluir diseños de interfaz o determinadas especificaciones técnicas.

La verdadera diferencia entre la definición de hecho y la definición de ready

La definición de hecho es un checklist, una lista cerrada de aspectos que se tienen que dar para considerar que un elemento del Product Backlog ha sido terminado. Un elemento está terminado o no lo está, según cumpla o no con la definición de hecho. La definición de ready, en cambio, implica el haber generado un entendimiento compartido dentro del equipo. Es decir, la definición de ready es de alguna manera más abstracta y tiene mucho que ver con la mentalidad con la que los miembros del Equipo Scrum afrontan (y preparan) cada Sprint. Aunque no es lo ideal, un elemento que no está ready al 100% puede ser seleccionado en la Sprint Planning y terminar de refinarse (y completarse) durante el Sprint.

Por supuesto, la otra diferencia entre ambas definiciones tiene que ver con el momento. La definición de ready importa a la hora de seleccionar un elemento durante la Sprint Planning, se evalúa antes de que el trabajo de desarrollo sobre aquel de comienzo. La definición de hecho nos ayuda a verificar que el trabajo de implementación del elemento ha concluido y que está en producción a disposición de los usuarios o podría estarlo de manera inmediata.

Refinamiento y definición de ready

Las reuniones de refinamiento son el foro idóneo en el que crear ese entendimiento compartido acerca de los elementos del Product Backlog. Nos permiten tener las conversaciones necesarias y añadir el detalle necesario para que cumpla con la definición de ready. En este sentido, la consideración de ready es consecuencia del refinamiento.

De igual modo, llegar a ready también implica trabajar colaborativamente, a menudo mediante reuniones e interacciones informales.

El riesgo de la definición de ready

El problema de tener una definición de ready como tal es que el Equipo de Desarrollo la utilice como “escudo” para, durante la Planning, rechazar elementos del Product Backlog que, aun no estando 100% ready, son prioritarios para el Product Owner y podrían completarse en el Sprint sin mayores problemas. Este comportamiento poco o nada tiene de Agile. Fomentemos la colaboración sincera, orientada a la maximización del valor del producto, y no construyamos barreras o contractos ficticios dentro del equipo.