Definition of Ready (y el Lado Oscuro)

Entre los elementos asociados a una Historia de Usuario, Item por extensión, entre elementos como el Valor, los Puntos Historia, los “By example”, y otros, están los “Definition”, donde el “Definition” más famoso es el “Definition of Done” (te dejo post, En un proyecto ágil, acordar una buena definición de lo que significa terminado). De todos los anteriores te he hablado en algún post, salvo de otro “Definition”, algo menos popular, pero que también lleva ahí años: el “Definition of Ready”.

El “Definition of Ready” son las pre-condiciones, las dependencias externas, la información, todo aquello que debe resolverse antes de ponerse a desarrollar una Historia de Usuario.

Algunos clásicos en el “Definition of Ready” refieren a la calidad de la Historia de Usuario, a que realmente sea una Historia de Usuario, y no una “epic”, que estén los ejemplos para la aceptación (los by example), etc.

Si una vez acordado el “Definition of Done” su cumplimiento cae, normalmente, bajo la responsabilidad del Equipo Técnico, mucho del “Definition of Ready” cae bajo la responsabilidad del Product Owner (no necesariamente todo, porque, por ejemplo, hay veces que se mete en el Ready que la Historia esté estimada, lo cual es responsabilidad del equipo).

Con todo esto, uno de los destacados en el “Definition of Ready” es lo relativo al diseño de la interfaz de usuario, los Mockups, o diseño de pantallas. Quizá este punto sea de los más identificados con el “Definition of Ready” (para ampliar aquí te recomiendo aquel post de ¿Cuándo se hace el diseño de interfaces (UI) y el UX en Scrum?)

El Lado Oscuro

Cuando suelo hablar con alguien de Agilidad, charlas, cursos, etc., si has estado lo recordarás, suelo contar que “el Lado Oscuro” del cascada y la visión “industrial” sabe esconderse bien para que caigas en él.

Todos ponemos caras de “claro hombre, eso NO hay que hacerlo”, cuando vemos el dibujo de un cascada “muy claro”, pero luego hay “Lado Oscuro” camuflado de Ágil por todos sitios y de ese no nos damos cuenta. “Lado Oscuro” como varios tableros por equipo, tableros con columnas cascada, Sprints por Proyectos, etc., y, en nuestro caso, conviene prevenirse… del “Definition of Ready” que lleva al Cascada.

En este caso, el problema con el “Definition of Ready” puede venir de controlar al extremo qué Items pueden entrar en un Sprint. De que montemos un proceso demasiado secuencial en vez de concurrente. De evitar que no se pueda comenzar a trabajar en algo hasta que una fase previa (determinada por el  “Definition of Ready”) esté completada al 100%.
Como todo, usa el “Definition of Ready” con moderación.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba