En este artículo quiero explicar qué son Definition of Done y Definition of Ready, cuáles son sus diferencias y cómo las utilizo en proyectos reales.

También voy a relacionar estos conceptos con principios más amplios de calidad que utilizo como referencia dentro del SAFe Framework .

¿Qué son Definition of Done y Definition of Ready?

Las dos definiciones ayudan a crear criterios más objetivos para el flujo de trabajo.

Yo las resumo de una forma muy sencilla:

Definition of Ready responde: “¿podemos empezar?”

Definition of Done responde: “¿podemos decir realmente que terminamos?”

La primera protege la entrada de una tarea en el proceso.

La segunda protege su salida.

Cuando ambas funcionan correctamente, el equipo comparte una comprensión mucho más clara sobre qué necesita existir antes de comenzar y qué significa realmente terminar.

¿Qué es Definition of Ready (DoR)?

La Definition of Ready (DoR) establece las condiciones mínimas que espero que una tarea cumpla antes de comenzar su ejecución.

No significa intentar descubrir absolutamente todo antes de empezar.

Los proyectos siempre contienen incertidumbre.

Pero existe una diferencia importante entre trabajar con incertidumbre y comenzar una tarea que nadie entiende suficientemente.

Dependiendo del proyecto, una Definition of Ready puede ayudarnos a comprobar preguntas como:

• ¿Está claro el problema que debemos resolver?
• ¿Está definido el objetivo de la tarea?
• ¿Sabemos cuál es el resultado esperado?
• ¿Los criterios de aceptación están documentados?
• ¿Las principales dependencias han sido identificadas?
• ¿Existe suficiente información técnica?
• ¿Los flujos principales y alternativos están claros?
• ¿El equipo tiene suficiente información para estimar el trabajo?
• ¿Las dudas críticas fueron resueltas?

Existe una regla práctica que utilizo:

Si durante el refinamiento el equipo todavía no entiende qué debe hacer, probablemente la tarea todavía no está ready.

¿Qué es Definition of Done (DoD) o definición de hecho?

La Definition of Done (DoD) establece las condiciones necesarias para considerar que una tarea o entrega está realmente terminada.

En español también encontrarás este concepto como definición de hecho.

Su objetivo es evitar situaciones como estas:

• El desarrollo terminó, pero las pruebas todavía no;
• Las pruebas terminaron, pero falta una validación;
• La funcionalidad está lista, pero la documentación no;
• La tarea aparece como Done en el board, pero todavía necesita volver al equipo.

En todos estos casos surge la misma pregunta:

¿La entrega está realmente Done?

Dependiendo del proyecto, mi Definition of Done puede incluir:

• Criterios de aceptación cumplidos;
• Validación funcional realizada;
• Pruebas ejecutadas correctamente;
• Pruebas automatizadas aprobadas;
• Revisión técnica concluida;
• Documentación actualizada;
• Estándares técnicos y de producto respetados;
• Aceptación formal de la entrega cuando sea necesaria.

El objetivo es que todo el equipo comparta una comprensión razonablemente objetiva de lo que significa decir:

“Terminamos.”

Diferencias entre Definition of Ready y Definition of Done

Para mí, la diferencia puede resumirse así:

Definition of Ready protege el inicio del trabajo.

Definition of Done protege su finalización.

La DoR intenta evitar que una tarea comience antes de tener las condiciones necesarias para ser ejecutada.

La DoD intenta evitar que una tarea salga del proceso antes de cumplir las condiciones que el equipo considera necesarias para una entrega terminada.

Cuando la Definition of Ready es débil, normalmente espero encontrar:

• Más dudas durante la ejecución;
• Más interrupciones;
• Más tiempo de espera;
• Estimaciones menos confiables;
• Mayor riesgo de retrabajo.

Cuando la Definition of Done es débil, puedo encontrar:

• Tareas cerradas antes de tiempo;
• Problemas descubiertos después de la entrega;
• Tareas reabiertas;
• Calidad inconsistente;
• Retrabajo después de lo que debería haber sido la finalización.

Definition of Done, Definition of Ready y criterios de aceptación no son lo mismo

Otro punto importante es no tratar DoR, DoD y criterios de aceptación como si fueran exactamente lo mismo.

Yo los separo de esta manera:

• Definition of Ready: ¿qué condiciones debe cumplir la tarea antes de comenzar?
• Criterios de aceptación: ¿qué condiciones específicas debe cumplir esa entrega?
• Definition of Done: ¿qué condiciones deben cumplirse para considerar el trabajo terminado?

Los criterios de aceptación pueden variar de una tarea a otra.

DoR y DoD ayudan a establecer un estándar compartido sobre las condiciones de entrada y salida del trabajo.

Ejemplo de Definition of Ready

En mis proyectos, para crear claridad y mejorar la documentación, suelo trabajar con un trípode formado por:

• PO — responsable de la expectativa de negocio;
• UI — responsable de los flujos y de la experiencia esperada;
• Tech Leader — responsable de la orientación técnica.

Para preparar una tarea:

• UI documenta el flujo esperado y los flujos alternativos;
• PO documenta lo que se espera como resultado de negocio;
• Tech Leader documenta las principales orientaciones técnicas.

¿Por qué utilizo este modelo?

Porque nunca parto de la premisa de que todas las personas que entran en un proyecto ya poseen todo el conocimiento de negocio, producto y tecnología necesario para tomar cualquier decisión.

Al principio, determinadas personas funcionan como referencias.

Con el tiempo, el objetivo es que el resto del equipo acumule conocimiento y autonomía suficientes para depender cada vez menos de ellas.

Este modelo de PO, UI y Tech Leader ya forma parte de la forma en que aplico Ready y Done en la práctica. :contentReference[oaicite:1]{index=1}

El refinamiento también forma parte de mi Definition of Ready

Cuando el equipo analiza una tarea durante el refinamiento y aparecen preguntas importantes que nadie puede responder, no intento simplemente empujarla hacia el sprint.

Las preguntas se convierten en nueva información que necesita ser aclarada.

La tarea vuelve para refinamiento hasta alcanzar un nivel de claridad suficiente.

No busco documentación perfecta.

Busco reducir dudas previsibles antes de que se transformen en bloqueos durante la ejecución.

Ejemplo de Definition of Done

Para la Definition of Done, también utilizo esas referencias para validar formalmente la entrega cuando sea necesario.

Además, suelo incluir pruebas como una capa importante de protección.

Dependiendo del proyecto, mi DoD puede considerar:

• Criterios de aceptación atendidos;
• Validación del PO;
• Validación de UI cuando sea necesaria;
• Peer review o revisión técnica;
• Casos de prueba ejecutados;
• Pruebas unitarias automatizadas aprobadas;
• Documentación actualizada;
• Estándares del proyecto respetados.

El objetivo es crear una barrera de seguridad.

Si una condición crítica todavía no se ha cumplido, la entrega no debería tratarse como terminada.

¿Por qué los equipos abandonan DoR y DoD?

Si estas definiciones ayudan tanto, ¿por qué desaparecen de tantos proyectos?

Tengo algunas hipótesis:

• Falta de experiencia de los líderes del equipo;
• Dificultad para convencer a otras personas sobre la importancia de las definiciones;
• Falta de autoridad o influencia de los líderes;
• Proyectos que ya están retrasados;
• Proyectos de innovación con mayor incertidumbre;
• Productos y proyectos sin un proceso claramente definido.

Hay un comportamiento que observo con frecuencia:

Cuando un proyecto está retrasado, empezamos a eliminar etapas que aparentemente consumen tiempo.

Reducimos refinamientos.

Comenzamos tareas antes de que estén suficientemente claras.

Reducimos validaciones.

El objetivo es acelerar.

Pero si estas decisiones generan más dudas, errores y retrabajo, terminamos perdiendo precisamente el tiempo que intentábamos ahorrar.

Antes de cambiar DoR y DoD, entiende quién necesita participar

Cuando el problema está relacionado con falta de influencia o autoridad, no intentaría imponer simplemente una nueva Definition of Ready o Definition of Done.

Primero alinearía estas definiciones con los stakeholders que tienen mayor influencia e impacto sobre el proyecto.

Hablo con más detalle sobre este tema en: Cómo usar la matriz de stakeholders para aumentar tu influencia y mejorar la comunicación del proyecto .

Definition of Ready y Definition of Done forman parte de una discusión mayor sobre calidad

Para mí, DoR y DoD no son conceptos aislados.

Forman parte de una discusión más amplia sobre la calidad del proceso que transforma una necesidad en una entrega.

Por eso me gusta relacionarlos con algunos de los conceptos de Built-In Quality de SAFe .

El artículo original ya conecta estas definiciones con Built-In Quality, shift learning left, peer review, collective ownership y automatización. :contentReference[oaicite:2]{index=2}

Shift learning left

En el desarrollo de productos siempre existen escenarios que solamente descubrimos mientras avanzamos.

Lo mismo ocurre con las tareas.

Pero cuanto más tarde descubrimos una duda, una dependencia o un problema importante, más difícil y costoso puede resultar corregirlo.

Eso puede afectar alcance, calidad, cronograma y costos.

Por eso intento anticipar preguntas y validaciones siempre que sea posible.

Pair programming y peer review

Pair programming y peer review pueden aportar otra perspectiva sobre cómo se construye una entrega.

Pero también existe una realidad:

Si dos personas trabajan en una tarea, no están trabajando en dos tareas diferentes.

La calidad tiene un costo.

Y casi todos los proyectos tienen presión por entregar más rápido.

Por eso estas prácticas deben analizarse según el riesgo, el contexto y la capacidad disponible.

Collective ownership y habilidades T-shaped

Otro objetivo importante es evitar que todo el conocimiento crítico permanezca concentrado en una sola persona.

Al inicio de un proyecto, o cuando entran nuevos profesionales, el conocimiento sobre las reglas de negocio, las decisiones anteriores y la arquitectura todavía puede ser bajo.

Ese conocimiento debe construirse y distribuirse progresivamente.

El objetivo no es que todos sepan absolutamente todo.

El objetivo es reducir dependencias que puedan convertirse en riesgos para el proyecto.

Estándares y Definition of Done

Todo profesional posee patrones de trabajo.

Cuando esos patrones son compartidos y documentados, pueden convertirse en estándares del proyecto.

Y esto está directamente relacionado con la Definition of Done.

Si cada persona tiene una interpretación diferente de lo que significa una entrega de calidad, el estado Done pierde valor.

Automatización del workflow

Los workflows suelen contener pasos manuales entre diferentes profesionales.

Cada paso puede generar espera.

El equipo también puede perder tiempo realizando inspecciones manuales o buscando componentes que ya existen.

Automatizar partes de este proceso puede ayudar a reducir tiempo, costos y tareas manuales.

En el artículo original, esta automatización ya está relacionada con tiempos de espera, eficiencia del flujo y el impacto que tareas poco claras pueden tener sobre cronograma, costos y performance. :contentReference[oaicite:3]{index=3}

DoR y DoD también afectan productividad y previsibilidad

Cuando una tarea comienza sin suficiente claridad, el tiempo perdido no desaparece.

Aparece durante la ejecución en forma de:

• Preguntas;
• Mensajes;
• Reuniones;
• Esperas;
• Retrabajo;
• Nuevas estimaciones;
• Retrasos.

De la misma forma, cuando una tarea se considera Done demasiado pronto, parte del trabajo vuelve posteriormente como corrección.

Por eso no veo Definition of Ready y Definition of Done únicamente como controles de calidad.

También ayudan a proteger el flujo, la productividad y la previsibilidad del proyecto.

Cómo Saint Jude ayuda a identificar problemas de Ready y Done

Jira, Azure DevOps, ClickUp, Monday.com, Asana y otras herramientas contienen una gran cantidad de información sobre las tareas y sobre cómo se mueve el trabajo.

Saint Jude funciona como una capa de inteligencia sobre estos datos.

El objetivo es ayudar a gerentes, PMOs y líderes a identificar señales como:

• Tareas que entran en ejecución sin información suficiente;
• Estimaciones que no coinciden con la ejecución real;
• Actividades que permanecen demasiado tiempo en determinados estados;
• Bloqueos recurrentes;
• Tareas reabiertas o devueltas para corrección;
• Retrabajo recurrente;
• Retrasos que pueden comprometer el cronograma;
• Impactos de problemas de calidad sobre costos y productividad.

No se trata de transformar Definition of Ready y Definition of Done en burocracia.

Se trata de entender si las reglas que el equipo ha definido están ayudando al trabajo a fluir mejor o si los mismos problemas continúan apareciendo.

Definition of Ready y Definition of Done no deberían existir solamente en un documento

Crear una DoR y una DoD no resuelve nada si se convierten en dos listas olvidadas en una página de documentación.

Necesitan formar parte de la manera en que el equipo trabaja.

La Definition of Ready debe ayudar a evitar que tareas sin las condiciones mínimas entren en ejecución.

La Definition of Done debe evitar que trabajo incompleto sea considerado terminado.

Y ambas deben evolucionar a medida que el equipo aprende.

Definition of Ready establece cuándo podemos comenzar. Definition of Done establece cuándo podemos decir realmente que hemos terminado.

Si quieres entender dónde tareas mal definidas, retrabajo, bloqueos y problemas de calidad están afectando fechas, productividad o costos, conoce Saint Jude y sus módulos de inteligencia de proyectos .

¿Y en tu equipo? ¿Definition of Ready y Definition of Done forman parte realmente del proceso o solamente aparecen cuando alguien recuerda que existen?

¡Hasta pronto!

Erik Scaranello