Una Definición de Listo que ayuda al equipo en vez de bloquearlo
La Guía de Scrum nunca menciona una Definición de Listo, y vale la pena decirlo sin rodeos. A diferencia de la Definición de Hecho, que es un compromiso formal con el Incremento, una Definición de Listo (DoR) es un acuerdo de trabajo opcional que un Equipo Scrum puede elegir adoptar. Bien usada, es un entendimiento compartido de cuándo un elemento del Product Backlog está lo bastante claro para entrar a un Sprint con confianza. Mal usada, se vuelve una barrera que mata de hambre al Sprint y erosiona la misma flexibilidad que Scrum existe para proteger.
En 2022, con equipos distribuidos asentándose en el trabajo híbrido y dependencias que se extienden por las cadenas de suministro, la tentación de formalizar en exceso la preparación es fuerte. La solución no es abandonar la idea, sino ser honestos sobre para qué sirve.
Cómo se ve una Definición de Listo útil
Una DoR útil es corta, pertenece a todo el Equipo Scrum y se trata como una guía y no como un contrato. Existe para hacer productivo el refinamiento y más rápida la Planificación del Sprint, no para devolverse el trabajo entre roles.
Son un puñado de comprobaciones conversacionales, no un formulario largo: el elemento tiene un resultado claro, el equipo entiende a grandes rasgos cómo lo abordará y es lo bastante pequeño para terminarlo dentro de un Sprint.
Las dependencias son visibles y están resueltas o tienen un plan, para que el equipo no apueste por algo fuera de su control.
Los criterios de aceptación capturan la intención y los ejemplos clave, sin intentar especificar cada detalle por adelantado.
Se revisa en las retrospectivas y se cambia cuando deja de ayudar, porque pertenece al equipo y no a una policía de procesos.
Cómo se ve una Definición de Listo dañina
La versión dañina suele empezar con buenas intenciones y endurecerse en una barrera. Las señales le resultan familiares a cualquiera que haya visto el refinamiento convertirse en un tribunal.
Se usa para rechazar elementos en la Planificación del Sprint. Si los Desarrolladores se niegan a discutir cualquier cosa que no esté 'Lista', el refinamiento se empujó aguas arriba sobre una sola persona y el equipo dejó de compartir el trabajo de entender.
Exige especificación completa antes de empezar cualquier trabajo. Requerir cada detalle, estimación y diseño por adelantado recrea una mini cascada y elimina el aprendizaje que debe ocurrir durante el Sprint.
Pertenece a alguien fuera del equipo. Cuando un gerente o un analista aparte decide qué cuenta como Listo, la DoR se vuelve una frontera de traspaso en vez de un acuerdo compartido, y la propiedad del backlog abandona al equipo en silencio.
Impide que el Product Owner ordene el backlog. Si un trabajo de alto valor no puede considerarse porque no pasó una lista de preparación, la lista ahora prevalece sobre el valor, lo que invierte todo el propósito del Product Backlog.
La postura más sana es tratar la Definición de Listo como un estímulo para un buen refinamiento, no como un permiso. El refinamiento continuo del Product Backlog, hecho poco a poco a lo largo del Sprint, suele hacer innecesaria una DoR pesada, porque los elementos llegan a la Planificación ya entendidos. Si tus reglas de preparación crean una fila de trabajo 'aún no Listo' y frenan la entrega, esa es la señal para simplificarlas, no para añadir más casillas que marcar.
Si las prácticas de preparación de tu equipo han derivado en una barrera que frena todo, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a reenfocar el refinamiento en el flujo y el valor.