Definition of Done: ejemplos y cómo redactarla

La Definition of Done (DoD) es uno de esos conceptos que parece obvio hasta que el equipo entrega algo que falló en producción, omitió una revisión o nunca quedó documentado. En ese momento, se vuelve urgente.

¿Qué es una Definition of Done (DoD)?

Una Definition of Done es una lista de verificación compartida y acordada de criterios que un elemento de trabajo debe cumplir antes de que el equipo lo considere completo. No "casi terminado". No "funciona en mi máquina". Terminado de verdad.

La DoD se aplica a cada incremento de trabajo en el mismo nivel: cada historia de usuario, cada Sprint, cada lanzamiento. No la redacta una sola persona y se impone desde arriba. La crea el equipo en conjunto, se publica en un lugar visible y se aplica de forma consistente. Cuando el trabajo cumple todos los puntos de la lista, está terminado. Cuando no los cumple, no lo está.

Datos clave: Definition of Done

• Los equipos con una DoD claramente documentada entregan un 28 % menos de defectos que los equipos sin una, según una investigación publicada en la revista Empirical Software Engineering (2018).
• El State of Agile Report 2023 (digital.ai) encontró que las prácticas inconsistentes y los estándares poco claros se encuentran entre las cinco razones principales por las que fracasan las transformaciones ágiles: la DoD aborda directamente ambas.
• Un estudio de Capers Jones encontró que corregir un defecto en producción cuesta entre 10 y 100 veces más que detectarlo durante el desarrollo; una DoD que incluye requisitos de pruebas y revisión es una de las herramientas de prevención de defectos de menor costo disponibles.

Definition of Done frente a criterios de aceptación

Estos dos términos se confunden constantemente y esa confusión genera problemas reales. Están relacionados, pero cubren ámbitos diferentes.

Los criterios de aceptación responden: ¿esta funcionalidad hace lo que se supone que debe hacer? La DoD responde: ¿el equipo ha hecho todo lo necesario para considerar este incremento listo para lanzamiento?

Una historia puede superar todos sus criterios de aceptación y aun así no pasar la DoD si, por ejemplo, la documentación no fue actualizada o el código no fue revisado. Ambas barreras deben superarse.

Algunos equipos también utilizan una Definition of Ready (DoR) en la entrada: una lista de condiciones que un elemento de trabajo debe cumplir antes de que el equipo lo incorpore a un Sprint. La DoD cierra el ciclo en la salida. Juntas, crean una barrera de calidad alrededor de todo el ciclo del Sprint. Consulte refinamiento del Backlog para ver cómo encaja la DoR en la preparación del Sprint.

Por qué importa una Definition of Done

Sin una DoD, "terminado" significa algo diferente para cada persona del equipo. Un developer considera terminada una funcionalidad cuando el código compila. El ingeniero de QA la considera terminada cuando pasan las pruebas. El tech lead la considera terminada cuando está revisada. El Product Owner la considera terminada cuando está desplegada. Ninguno está equivocado. Pero si nunca se alinean en un único estándar, el equipo seguirá entregando trabajo que está parcialmente terminado de formas que nadie anticipó.

Esto es lo que ocurre en la práctica. Un equipo sin DoD:

• Entrega código que funciona localmente pero falla en staging porque las verificaciones de entorno no formaban parte de la lista mental de nadie
• Fusiona trabajo que fue "revisado" por la misma persona que lo escribió
• Acumula deuda de documentación porque nadie lo registró como requisito
• Pasa la mitad de la retrospectiva del Sprint discutiendo qué significa realmente "terminado" para las historias que acaban de completar

Un equipo con DoD:

• Tiene un estándar compartido e innegociable que no depende de la interpretación individual
• Detecta las brechas durante el Sprint, no después del despliegue
• Reduce el retrabajo porque todos conocen los criterios de salida antes de comenzar
• Avanza más rápido porque hay menos sorpresas en la revisión del Sprint

La DoD también protege el product backlog de completaciones falsas. Cuando una historia se marca como terminada sin cumplir todos los criterios, el trabajo real (las correcciones, la revisión, la documentación) queda enterrado en algún lugar del Backlog y resurge más tarde como trabajo no planificado.

Niveles de terminado

La mayoría de los equipos opera con tres niveles de terminado. Cada nivel tiene su propia lista de verificación y una lista de nivel superior generalmente incluye todo lo del nivel inferior.

Terminado a nivel de historia

Esta es la lista aplicada a las historias de usuario o tareas individuales. Cubre el trabajo específico requerido para entregar un incremento:

• Código escrito y revisado por uno mismo
• Pruebas unitarias escritas y pasando
• Código revisado por al menos otro miembro del equipo
• Criterios de aceptación cumplidos y verificados
• Rama de la funcionalidad fusionada a main (o la rama de integración acordada)

Terminado a nivel de Sprint

Esta lista se aplica al incremento completo del Sprint: la suma de todas las historias completadas en el Sprint. Suele añadir criterios de integración y despliegue:

• Todos los elementos de la DoD a nivel de historia cumplidos para cada historia incluida
• Pruebas de integración pasando contra el build completo
• Desplegado en el entorno de staging
• Objetivo del Sprint alcanzado o evaluado explícitamente
• Notas de lanzamiento o registro de cambios actualizado

Terminado a nivel de lanzamiento

Esto cubre todo lo necesario antes de que el incremento llegue a los usuarios de producción. Aquí es donde suelen residir los criterios de cumplimiento, rendimiento y aprobación:

• Pruebas end-to-end pasando en un entorno similar a producción
• Indicadores de rendimiento cumplidos (tiempo de carga, tasa de error, etc.)
• Análisis de seguridad completado sin hallazgos críticos
• Documentación actualizada y publicada
• Aprobación de las partes interesadas obtenida
• Plan de reversión documentado

Los equipos que trabajan en planificación del sprint deben tener claro qué nivel de terminado aplica a la entrega de cada Sprint. No todos los Sprints concluyen con un lanzamiento a producción, pero el equipo debe saber exactamente cuál es el estándar antes de comenzar.

Ejemplos de Definition of Done

A continuación se presentan listas de verificación de DoD concretas para tres tipos de equipos comunes. No son plantillas para copiar textualmente: son puntos de partida. La DoD de su equipo debe reflejar sus estándares, herramientas y flujo de trabajo reales.

Equipo de desarrollo de software (nivel de historia)

• Código escrito y compilado sin errores
• Pruebas unitarias escritas para la nueva lógica, con al menos un 80 % de cobertura en los archivos modificados
• Código revisado y aprobado por al menos otro developer
• Todas las pruebas automatizadas pasando en el pipeline de integración continua
• Sin nuevos errores de linting introducidos
• Funcionalidad desplegada en el entorno de staging y verificada con pruebas de humo
• Criterios de aceptación verificados por el developer o QA
• Cualquier nueva API o cambio de configuración documentado en el wiki del equipo
• Feature flag o toggle implementado si el trabajo no está listo para un despliegue completo

Equipo de marketing y contenidos (nivel de historia)

• Contenido redactado según el recuento de palabras y las pautas de tono acordados
• Revisado por un segundo redactor o editor en cuanto a precisión y voz de marca
• Lista de verificación de SEO completada (etiqueta de título, meta descripción, palabra clave objetivo en H1)
• Todos los enlaces internos verificados y funcionando
• Imágenes optimizadas y texto alternativo añadido
• Programado o publicado en el CMS según el calendario de contenidos
• Tareas de distribución completadas (publicaciones en redes sociales programadas, inclusión en newsletter confirmada)
• Seguimiento de análisis confirmado (parámetros UTM, etiquetas de eventos implementadas)

Equipo de diseño (nivel de historia)

• El diseño coincide con el brief aprobado o los requisitos de la historia de usuario
• Revisado por el diseñador principal y las partes interesadas relevantes
• Pautas de accesibilidad verificadas (contraste de color, tamaño de tipografía, flujo de teclado para elementos interactivos)
• Todos los estados documentados: predeterminado, hover, enfoque, error, vacío, cargando
• Recursos exportados en los formatos requeridos y subidos a la biblioteca de diseño compartida
• Notas de transferencia escritas para el equipo de desarrollo
• Cualquier comentario abierto de la revisión resuelto o explícitamente diferido con una justificación

Cómo redactar una Definition of Done

Paso 1: Reúna al equipo

La DoD solo funciona si todos creen en ella. Eso significa crearla en conjunto: developers, diseñadores, QA, Product Owners, todos los que hacen el trabajo. Un taller de 60 minutos suele ser suficiente para obtener una primera versión. No deje que el Scrum Master o el líder del equipo la redacte solo y la presente para "aprobación". La co-creación es el punto central.

Paso 2: Liste lo que realmente requiere la completación

Comience preguntando al equipo: "Piensen en el último trabajo que entregaron que volvió con un problema. ¿Qué paso se omitió?" Trabaje hacia atrás desde los fallos para encontrar los elementos de la lista que importan. Luego trabaje hacia adelante: ¿cómo se ve una buena entrega? ¿Qué nos avergonzaría haber olvidado?

Agrupe los elementos por categorías: calidad del código, pruebas, documentación, despliegue, revisión. Esto facilita revisar la DoD durante el Sprint.

Paso 3: Asegúrese de que cada elemento sea verificable

Cada elemento de la DoD debe poder comprobarse: o está hecho o no lo está. "La calidad del código es buena" no es un elemento de la DoD. "Código revisado y aprobado por al menos un miembro del equipo que no sea el autor" sí lo es. La prueba: ¿puede señalar evidencia de que este elemento fue completado? Si la respuesta es sí, pertenece a la DoD. Si requiere criterio subjetivo, conviértalo en una pauta o divídalo en criterios más específicos.

Paso 4: Acuerde y publíquelo en un lugar visible

Una vez que el equipo tenga un borrador, obtenga un acuerdo explícito. No "sin objeciones", sino un compromiso real. Publique la DoD en algún lugar que todo el equipo vea cada día: el tablero del Sprint, el wiki del equipo, la descripción del canal en Slack. No debe ser un documento enterrado en una carpeta que nadie abre. Si el equipo no puede verla, no la usará.

Paso 5: Revísela y hágala evolucionar

La DoD no es permanente. Debe revisarse en la retrospectiva del sprint cada vez que el equipo entregue algo que exponga una brecha. Cuando el equipo añade una nueva herramienta (por ejemplo, un analizador de seguridad automatizado), agréguela a la DoD. Cuando un elemento de la lista se vuelve tan automático que nadie lo omite, evalúe si aún necesita estar escrito o si ya es simplemente un hábito del equipo.

Una DoD que nunca cambia o es perfecta (poco probable) o está siendo ignorada (más probable).

Errores comunes

Hacerla demasiado larga. Una DoD de 30 elementos no se usa. Apunte a 8 o 12 elementos que cubran sus brechas de calidad reales, no un ideal exhaustivo. Si no puede recitar la DoD de memoria después de una semana, es demasiado larga.

Redactarla a nivel organizacional en lugar de a nivel de equipo. Una DoD impuesta desde el liderazgo cubre política, no práctica. Cada equipo necesita una DoD que refleje su flujo de trabajo, herramientas y estándares reales.

Tratarla como algo aspiracional. Si el equipo no puede cumplir de forma realista todos los elementos de la DoD en un Sprint normal, la DoD es aspiracional, no operativa. Recórtela a lo que el equipo puede comprometerse realmente y luego eleve el estándar gradualmente a medida que mejoren la capacidad y las herramientas.

Omitirla en momentos de presión. "Nos saltaremos la documentación en este Sprint porque estamos justos de tiempo" es el momento en que la DoD deja de significar algo. Las excepciones parciales se acumulan y se convierten en excepciones constantes. Si la DoD puede suspenderse bajo presión, nunca fue un estándar real.

Olvidar los requisitos no funcionales. El comportamiento funcional está cubierto por los criterios de aceptación. La DoD es donde residen los estándares de rendimiento, seguridad, accesibilidad y documentación. Los equipos que los excluyen de la DoD entregan funcionalidades que funcionan pero degradan el sistema con el tiempo.

Preguntas frecuentes

¿Quién es el dueño de la Definition of Done?

El equipo la posee colectivamente. El Product Owner puede influir en ella (le importa la capacidad de lanzamiento) y el Scrum Master puede facilitar su creación y revisión. Pero en Scrum, los Developers son quienes se comprometen a cumplir la DoD para cada incremento. Nadie puede cambiarla unilateralmente a mitad de un Sprint.

¿Cuál es la diferencia entre una Definition of Done y una lista de verificación?

Una DoD es un tipo de lista de verificación, pero con un propósito específico y un contrato específico detrás. Una lista de verificación es una herramienta. La DoD es un acuerdo de que cada incremento debe superar esta barrera antes de que el equipo lo considere terminado. La distinción importa porque implica responsabilidad compartida y consecuencias: el trabajo que no cumple la DoD no se contabiliza en el objetivo del Sprint.

¿Todo equipo necesita una Definition of Done?

Sí, si el equipo entrega trabajo del que dependen otras personas. La DoD es el mecanismo que hace que "terminado" signifique lo mismo para todos. Los equipos sin una desarrollan estándares implícitos (que no se comparten ni se aplican) o discuten sobre qué significa "terminado" en los peores momentos, generalmente al final de un Sprint.

¿Puede la Definition of Done ser diferente para distintos tipos de trabajo?

Sí, con precaución. Muchos equipos tienen una DoD a nivel de historia y una DoD a nivel de Sprint (como se describe en la sección de niveles anterior). Algunos equipos tienen criterios ligeramente diferentes para correcciones de errores frente a nuevas funcionalidades. Pero tenga cuidado con la fragmentación. Cuantas más excepciones y casos especiales tenga la DoD, más carga cognitiva genera y menos confiablemente se aplica.

¿Cómo se relaciona la Definition of Done con los story points?

Los story points estiman el esfuerzo relativo. La DoD define los estándares de calidad. Están relacionados porque la DoD debe tenerse en cuenta en las estimaciones: si cumplir la DoD para una historia requiere 3 horas adicionales, ese tiempo debe reflejarse en la estimación de story points, no tratarse como gastos generales que se omiten cuando el equipo está bajo presión. Cuando los equipos subestiman las historias porque no tienen en cuenta los requisitos de la DoD, acaban en exactamente el tipo de presión que conduce a atajos en la DoD.

---

Una Definition of Done bien elaborada no ralentiza a un equipo. Elimina la ambigüedad que ralentiza a los equipos. Cuando todos saben exactamente qué significa "terminado" antes de comenzar, hay menos sorpresas, menos ciclos de retrabajo y menos discusiones en la revisión del Sprint. Comience con algo simple, aplíquelo de forma consistente y deje que evolucione a medida que lo hace el equipo.

Lectura relacionada

• Product backlog
• Refinamiento del Backlog
• Historias de usuario
• Story points
• Retrospectiva del sprint
• Planificación del sprint
• ¿Qué es Scrum?