Una definición de «listo» que de verdad ayuda (y las formas en que los equipos la arruinan)
Una definición de «listo» (DoR) es un acuerdo compartido sobre cuándo un elemento del Product Backlog es lo bastante claro para incorporarse a un Sprint. Conviene decirlo de entrada: no forma parte de la Guía Scrum. La Guía nombra la definición de «terminado» como un compromiso formal, pero la definición de «listo» es un acuerdo de trabajo opcional que un equipo puede decidir adoptar. Esa distinción importa, porque los errores más comunes vienen de tratarla como una regla impuesta en lugar de una herramienta que el equipo posee.
Bien usada, una DoR es una comprobación rápida antes de la Planificación del Sprint: ¿entendemos este elemento, podemos estimarlo y podríamos plausiblemente terminarlo dentro de un Sprint? Cuando el trabajo remoto dispersó a los equipos por distintas zonas horarias en 2021, esa comprobación demostró su valor —no puedes asomarte a un escritorio para preguntar qué significaba un elemento vago cuando quien lo escribió está desconectado hasta mañana. Elementos lo bastante claros permiten a los equipos distribuidos planificar con confianza en lugar de adivinar.
Los errores que la echan a perder
Convertirla en una barrera pesada. En cuanto una DoR se vuelve una lista larga que cada elemento debe satisfacer antes de que nadie pueda tocarlo, el refinamiento se atasca y los elementos se acumulan esperando una claridad perfecta. Scrum acoge el detalle que emerge; una DoR debe elevar la madurez, no exigir una certeza que aún nadie tiene.
Confundirla con la definición de «terminado». «Listo» trata de si el trabajo puede empezar; «terminado» trata de si el trabajo está acabado y es entregable. Mezclarlos enturbia ambos. «Terminado» es un verdadero compromiso de Scrum que rige la calidad; «listo» es una ayuda a la planificación. Mantén dos conversaciones separadas.
Escribirla para el equipo en lugar de con él. Una DoR impuesta por un gerente o un único Scrum Master rara vez prende. Son los Desarrolladores y el Product Owner quienes sufren los elementos poco claros, así que deben dar forma al acuerdo. La apropiación es lo que hace que un equipo realmente la use.
Exigir que la estimación esté en la DoR. Algunos equipos exigen una estimación en puntos antes de que un elemento esté «listo», y luego no pueden estimar porque el elemento es confuso —un punto muerto. Mejor: exige suficiente entendimiento compartido para que la estimación sea posible, y deja que la estimación surja durante el refinamiento.
No revisarla nunca. Una DoR redactada hace un año para un equipo colocalizado puede no encajar en uno híbrido. Trátala como un acuerdo vivo y ajústala en la Retrospectiva cuando deje de ganarse su lugar.
Cómo es una DoR útil
Mantenla corta y centrada en el resultado. Una DoR práctica suele pedir solo unas pocas cosas: el elemento describe un resultado o necesidad de usuario clara; existen criterios de aceptación y se entienden; las dependencias son conocidas; y el equipo cree que es lo bastante pequeño para terminarlo en un Sprint. Eso basta para planificar con confianza sin congelar el backlog.
Trátala como una guía que el equipo aplica con criterio, no como una barrera rígida de aprobado/reprobado
Constrúyela y revísala en el refinamiento y en las Retrospectivas, donde el equipo ya posee el trabajo
Apunta a «lo bastante claro para empezar y terminar», no a «totalmente especificado de antemano»
Una definición de «listo» está en su mejor momento cuando es casi invisible —un hábito discreto que mantiene el trabajo a medio formar fuera del Sprint sin volverse burocracia. Si te frena, esa es la señal de simplificarla.
Si tus equipos de entrega están atrapados entre requisitos vagos y un proceso rígido, la asesoría en ejecución de programas y proyectos de XNM puede ayudarte a encontrar el equilibrio que funciona.