¿Qué es el Definition of Ready (DoR)?

El Definition of Ready (DoR), o Definición de Listo en español, es un conjunto de criterios acordados por el equipo Scrum que establece las condiciones mínimas que un elemento del Product Backlog (PBI - Product Backlog Item) debe cumplir antes de ser seleccionado para su desarrollo en un Sprint.

En esencia, el DoR responde a la pregunta: "¿Esta historia de usuario está lo suficientemente clara, detallada y preparada para que el equipo pueda trabajar en ella sin bloqueos?"

Es el complemento del Definition of Done (DoD): mientras el DoD define cuándo un elemento se considera "terminado", el DoR define cuándo está "listo" para comenzar.

Los criterios varían según el equipo y la organización, pero estos son los más comunes:

Criterios fundamentales

Criterio	Descripción
Historia de usuario clara	Formato "Como [rol], quiero [acción], para [beneficio]" bien definido
Criterios de aceptación	Condiciones específicas y verificables que definen cuándo la historia está completa
Estimación	El equipo ha estimado la historia (story points, tallas, etc.)
Tamaño adecuado	La historia puede completarse dentro de un Sprint
Sin dependencias bloqueantes	Las dependencias externas están resueltas o tienen un plan
Diseño/Mockups	Si aplica, los diseños están disponibles y aprobados
Datos de prueba	Los datos necesarios para pruebas están identificados

Ejemplo de DoR completo

Un equipo podría definir su DoR así:

Una historia de usuario está "Ready" cuando:

1. Tiene una descripción clara en formato de historia de usuario
2. Los criterios de aceptación están escritos y acordados con el Product Owner
3. Ha sido estimada por el equipo de desarrollo
4. Cabe en un Sprint (no supera X story points)
5. Las dependencias externas están identificadas y resueltas
6. Los mockups o wireframes están disponibles (si aplica)
7. El equipo entiende la historia y no tiene preguntas pendientes
8. Los criterios de aceptación son verificables/testables
9. Las consideraciones de rendimiento y seguridad están identificadas

No es parte oficial de Scrum

Es importante señalar que el DoR no forma parte del Scrum Guide oficial. A diferencia del Definition of Done, que es un componente formal de Scrum, el DoR es una práctica complementaria que algunos equipos adoptan voluntariamente.

La Scrum Guide establece que el Refinamiento del Product Backlog es la actividad donde los elementos se detallan y preparan para futuros Sprints. El DoR puede verse como una formalización de los criterios de refinamiento adecuado.

Sprint Planning y DoR

Durante el Sprint Planning, el equipo selecciona elementos del Product Backlog para el Sprint. El DoR ayuda en este momento:

1. Los elementos que cumplen el DoR pueden ser seleccionados con confianza
2. Los elementos que no lo cumplen se identifican como "no listos" y no entran al Sprint
3. El Sprint Planning se vuelve más eficiente al reducir las discusiones sobre elementos mal definidos

Refinamiento y DoR

El Refinamiento del Backlog (o Grooming) es donde los elementos se preparan para cumplir el DoR:

• El Product Owner presenta los elementos de mayor prioridad
• El equipo hace preguntas para clarificar
• Se definen los criterios de aceptación
• Se estima el esfuerzo
• Se identifican dependencias y riesgos

El DoR actúa como una checklist que guía el refinamiento: cuando todos los criterios se cumplen, el elemento está listo.

Reduce la incertidumbre

Al asegurar que los elementos están bien definidos antes de comenzar, el equipo reduce significativamente las sorpresas durante el Sprint.

Mejora la eficiencia del Sprint

Los equipos pasan menos tiempo clarificando requisitos durante el Sprint y más tiempo desarrollando. Esto reduce el desperdicio y mejora el flujo.

Facilita la estimación

Elementos bien definidos son más fáciles de estimar con precisión, lo que mejora la predictibilidad del equipo.

Promueve la colaboración

El DoR fomenta la comunicación entre el Product Owner y los Developers durante el refinamiento, asegurando un entendimiento compartido.

Reduce el riesgo

Al identificar dependencias, riesgos y ambigüedades antes del Sprint, el equipo puede abordarlos proactivamente.

A pesar de sus ventajas, el DoR es frecuentemente considerado un antipatrón en Scrum. Las razones principales son:

Contradice el empirismo

Scrum se basa en el control empírico de procesos: inspección, adaptación y transparencia. Un DoR rígido puede impedir que el equipo responda a cambios o trabaje con información parcial, que es precisamente lo que el empirismo permite.

Puede crear una barrera de comunicación

Si el DoR se convierte en un "filtro burocrático", puede reducir la comunicación directa entre el Product Owner y los Developers:

• "No puedo trabajar en esto porque no cumple el DoR" en lugar de "Hablemos para clarificar esto"
• El equipo espera pasivamente que el PO "cumpla el DoR" en lugar de colaborar activamente

Reduce la autonomía del equipo

Un DoR estricto puede hacer que el equipo dependa excesivamente de que otros (Product Owner, stakeholders, diseñadores) completen su parte, en lugar de buscar proactivamente la información necesaria.

Puede retrasar el inicio del trabajo

Si un elemento no cumple todos los criterios del DoR pero el equipo podría empezar a trabajar en él con un nivel razonable de información, el DoR puede causar retrasos innecesarios.

Falsa sensación de seguridad

Cumplir el DoR no garantiza que no habrá problemas durante el desarrollo. Los equipos pueden caer en la trampa de pensar "si cumple el DoR, todo saldrá bien".

Usar el DoR cuando:

• El equipo es nuevo en Scrum y necesita estructura adicional
• El refinamiento del backlog es consistentemente pobre
• Los Sprints fallan frecuentemente por historias mal definidas
• Hay muchas dependencias externas que deben gestionarse
• El Product Owner es nuevo y necesita guía sobre qué información proporcionar

Evitar el DoR cuando:

• El equipo es maduro y tiene buena comunicación con el Product Owner
• El DoR se convierte en una barrera más que en una ayuda
• Los miembros del equipo lo usan como excusa para no trabajar en elementos ambiguos
• Impide la experimentación y el aprendizaje incremental

Enfoque recomendado

Usar el DoR como una herramienta temporal de aprendizaje:

1. Introducir el DoR cuando el equipo necesita mejorar su refinamiento
2. Evaluar regularmente si el DoR está ayudando o creando burocracia
3. Relajar los criterios a medida que el equipo madura
4. Retirar el DoR cuando el equipo naturalmente produce elementos bien refinados

Aspecto	DoR (Definition of Ready)	DoD (Definition of Done)
Cuándo	Antes de comenzar el trabajo	Cuando el trabajo se completa
Pregunta	"¿Está listo para empezar?"	"¿Está realmente terminado?"
Responsable	Product Owner + Developers	Developers
Oficial en Scrum	No	Sí
Enfoque	Calidad de la entrada	Calidad de la salida

Juntos forman un ciclo de calidad:

DoR → Trabajo del Sprint → DoD (entrada) (salida)

Es importante distinguir entre estos dos conceptos:

• Criterios de aceptación: Son específicos de cada historia de usuario. Definen las condiciones que la funcionalidad debe cumplir.
• DoR: Es genérico para todas las historias. Define las condiciones que la historia como artefacto debe cumplir.

El DoR puede incluir "tener criterios de aceptación definidos" como uno de sus criterios, pero los criterios de aceptación en sí son parte del contenido de la historia, no del DoR.

El acrónimo INVEST es un excelente complemento para el DoR:

Letra	Criterio	Significado
I	Independent	No depende de otras historias
N	Negotiable	Los detalles son negociables
V	Valuable	Aporta valor al usuario/negocio
E	Estimable	El equipo puede estimarla
S	Small	Es lo suficientemente pequeña para un Sprint
T	Testable	Se puede verificar su cumplimiento

¿Quién define el DoR?

El DoR debe ser definido colaborativamente por todo el equipo Scrum: Product Owner y Developers. No debe ser impuesto unilateralmente por ninguna parte.

¿El DoR se puede cambiar?

Sí, y debería revisarse regularmente. Las retrospectivas son un excelente momento para evaluar si los criterios del DoR siguen siendo útiles o necesitan ajuste.

¿Qué hago si una historia no cumple el DoR pero es urgente?

El equipo puede decidir trabajar en ella asumiendo el riesgo, pero debe ser una decisión consciente. La urgencia no elimina la necesidad de claridad; simplemente cambia la tolerancia al riesgo.

¿El DoR aplica solo a historias de usuario?

No necesariamente. Puede aplicarse a cualquier tipo de elemento del Product Backlog: historias de usuario, bugs, spikes, tareas técnicas, etc. Los criterios pueden variar según el tipo.

¿Cómo evito que el DoR se convierta en burocracia?

Mantén el DoR simple y práctico: 5-7 criterios máximo. Revísalo regularmente. Si el equipo siente que es una carga en lugar de una ayuda, simplifícalo o elimínalo. El objetivo es facilitar el trabajo, no complicarlo.