Cuando trabajamos con metodologías ágiles es muy importante que las tareas estén realmente listas antes de priorizarlas para trabajar en ellas. La falta de información, un alcance mal definido, o dependencias no contempladas, entre otros, son indicadores de una tarea que no ha sido correctamente preparada para trabajar en ella y una buena candidata a sufrir bloqueos y desperdicios. Contar con un Definition of Ready (DoR) nos ayuda a evitar este tipo de situaciones y hacer más eficiente nuestro trabajo.
Imaginemos el siguiente escenario. Han pasado ya unos días desde que refinamos nuestro Product Backlog con el resto del equipo, creemos tenerlo todo claro y estamos motivados y dispuestos a comenzar a trabajar.
Comenzamos leyendo la información que, junto al resto del equipo, hemos escrito para describir el elemento concreto de nuestro backlog. Aparentemente los requisitos son claros y se entienden perfectamente.
Pero entonces descubrimos que para poder ponernos manos a la obra es necesario disponer antes de unos recursos que no están listos, que requerirán tiempo para estarlo y que parece que no se han tenido en cuenta en ningún momento. En definitiva, nos damos cuenta de que no podemos comenzar a trabajar en el elemento priorizado. No es accionable.
¿Os suena de algo? Estoy convencido de que muchos de vosotros os habéis encontrado con esta situación en alguna ocasión.
En este momento lo primero que debemos hacer es informar al equipo del problema. La daily meeting puede ser un buen momento. Es posible que necesitemos replantear el alcance o pedirle a alguno de nuestros compañeros que nos facilite los recursos necesarios. Sea cual sea la decisión del equipo, reconducir la situación supondrá un desperdicio de tiempo que podríamos haber evitado.
En este caso ha fallado la identificación de dependencias externas. Este es solo uno de los inconvenientes que nos podemos encontrar cuando un elemento de nuestro backlog no dispone de un Definition of Ready correctamente definido.
El Definition of Ready reúne los requisitos que debe cumplir cualquier elemento del backlog para ser considerado listo para ejecutar, evitando de esta manera bloqueos y desperdicios.
Un caso clásico para aquellos que hemos trabajado en desarrollo mobile, es el de no disponer de los recursos visuales necesarios para poder desarrollar una funcionalidad concreta. En estas circunstancias es posible que nuestro compañero diseñador sea un crack y nos facilite los recursos que necesitamos en un abrir y cerrar de ojos. Aún así nuestra responsabilidad como miembros del equipo es tratar de evitar estas situaciones, identificar la oportunidad de mejora y exponerla al resto del equipo para mejorar el Definition of Ready.
Llegado a este punto seguro que muchos de vosotros os estaréis preguntando, ¿Qué información debe contener el Definition of Ready?
Sobre la información que debe contener el Definition of Ready no existe nada escrito en piedra. El equipo es quien debe decidir de manera consensuada qué aspectos debe reunir e ir identificando de manera emergente las posibles mejoras a incluir en él. Las retrospectivas pueden ser un buen momento para compartir con el resto del equipo las percepciones y posibles mejoras.
Existen varios métodos que nos pueden ayudar a definir el Definition of Ready. En este post nos centraremos en uno que ha dado mucho de qué hablar desde que salió a la luz de la mano de Bill Wake en 2003. Se trata del método INVEST.
INVEST
El nombre es un acrónimo de los siguientes conceptos, los cuales debería cumplir cualquier elemento de nuestro backlog:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent
El alcance debe ser autocontenido. Es decir, no deben existir dependencias externas que requieran ser resueltas antes de comenzar a trabajar. El ejemplo que comentábamos anteriormente vulnera este concepto en particular.
Negotiable
No son contratos. Se debe dar margen a la negociación o a la inclusión de mejoras emergentes que puedan surgir durante el desarrollo.
Un error común es querer aportar demasiada información de antemano, anticipándonos a aspectos o mejoras que puedan surgir de manera emergente. Es importante captar la esencia del valor que queremos aportar, más que los detalles concretos. Esto nos lleva al siguiente concepto.
Valuable
Es importante tener presente la figura del cliente y centrarnos en el valor que le puede aportar cada evolución de nuestro producto por muy pequeña que sea.
Estimable
El alcance e información deben ser lo suficientemente claros como para que sea sencillo realizar una estimación.
Un elemento de nuestro backlog difícil de estimar es un candidato claro para ser dividido en unidades más pequeñas que faciliten las estimaciones. Algo que nos lleva al siguiente punto.
Small
Este concepto se relaciona de forma transversal con el resto. Trabajar en unidades pequeñas de valor nos permite entregar valor al cliente más rápido, además de facilitar las estimaciones y priorizaciones.
Testable
Y a modo introductorio del último concepto de INVEST, es importante sumar otro punto a favor que tiene trabajar sobre unidades pequeñas de valor: La facilidad de testeo que ofrecen las mismas.
Poder plantear tests funcionales a partir de la información provista demuestra que existe un correcto entendimiento por parte del equipo de lo que se quiere llevar a cabo. Que surjan dudas a la hora de plantear tests funcionales sobre la nueva funcionalidad en cuestión es un indicador de que tal vez la información no sea lo suficientemente clara.
Es importante que para sacar el máximo partido a este concepto el equipo entienda la importancia del testing y que disponga de las habilidades necesarias para poder plantear los tests necesarios.
Entonces, ¿Es suficiente con seguir INVEST?
Si bien INVEST es un método que nos puede ser de gran utilidad, este no deja de ser una herramienta más a tener en cuenta a la hora de definir nuestro Definition of Ready.
El equipo, a través de una comunicación fluida, encontrará oportunidades de mejora en el proceso de trabajo de forma emergente. Por esta razón es importante trabajar en construir un entorno colaborativo en donde cada miembro del equipo pueda exponer sus opiniones libremente.
Conclusión
Espero haberos convencido de la importancia que ha de darse al Definition of Ready para lograr flujos de trabajo eficientes.
Si os ha parecido de utilidad el método INVEST os animo a que echéis un vistazo a la publicación original que escribió Bill Wake sobre el mismo, de la cual he extraído la mayor parte de información para describirlo en este post.
¡Os animo a que compartáis vuestras opiniones y experiencias en la sección de comentarios!
