Definition of Done y calidad del incremento

En el mundo del desarrollo ágil, la Definition of Done (DoD) es uno de los conceptos fundamentales que diferencia un equipo verdaderamente ágil de uno que simplemente sigue ceremonias ágiles sin substance. La DoD representa un acuerdo formal del equipo sobre qué significa que un elemento del Product Backlog esté verdaderamente completado, no solo "terminado" de forma parcial.

¿Qué es la Definition of Done?

La Definition of Done es un contrato social entre todos los miembros del equipo Scrum que establece los criterios mínimos que cada elemento del Product Backlog debe cumplir para considerarse un incremento potencialmente liberable. A diferencia de los criterios de aceptación, que son específicos de cada historia de usuario, la DoD se aplica a todos los elementos del backlog sin excepción.

Imagina que construyes una casa. Los criterios de aceptación serían específicos: "la puerta principal debe tener tres cerraduras". Pero la Definition of Done serían los estándares de construcción: cimientos sólidos, estructura de carga correcta, instalaciones eléctricas certificadas, acabados completos. Sin estos estándares, tendrías una casa con puertas y ventanas pero inhabitable.

Componentes esenciales de una Definition of Done

Una DoD efectiva debe incluir como mínimo los siguientes elementos:

Código completo y funcional: Todo el código necesario para implementar la funcionalidad ha sido escrito y se integra correctamente con el sistema existente.
Pruebas unitarias: El código cuenta con pruebas unitarias que cubren las funcionalidades principales, típicamente con un mínimo del 80% de cobertura.
Revisión de código: Al menos otro desarrollador ha revisado el código y ha dado su aprobación formal.
Pruebas de integración: Las nuevas funcionalidades se han probado en un entorno que simula el ambiente de producción.
Documentación actualizada: La documentación técnica se ha actualizado para reflejar los cambios realizados.
Criterios de aceptación cumplidos: Todas las condiciones definidas para la historia de usuario han sido verificadas.
No hay deuda técnica conocida: No se han introducido problemas de calidad intencionalmente para "luego".
Despliegue en producción (opcional según el equipo): El incremento está listo para ser desplegado si así se decide.

La DoD como herramienta de calidad

La Definition of Done actúa como un escudo protector contra la acumulación de trabajo incompleto. Sin una DoD clara, los equipos tienden a acumular lo que se conoce como "trabajo en progreso" o WIP por sus siglas en inglés. Este trabajo aparentemente "terminado" pero no liberable genera deuda técnica que se acumula comointerest compuesto: cada Sprint que pasa, la carga de trabajo pendiente crece exponencialmente.

"Un incremento sin Definition of Done no es un incremento, es una promesa de trabajo futuro."

Ejemplo práctico de Definition of Done

Consideremos un equipo de desarrollo de software para una aplicación bancaria:

Nuestra Definition of Done para el Sprint incluye:

✓ Código entregado en el repositorio principal (branch main/master)
✓ Cobertura de pruebas unitarias mínima del 85%
✓ Todas las pruebas unitarias pasan exitosamente
✓ Code review completado con al menos 2 aprobaciones
✓ Pruebas de integración automáticas pasan en CI/CD
✓ Análisis estático de código (SonarQube) sin bloqueos críticos
✓ Documentación de API actualizada en Swagger/OpenAPI
✓ Pruebas de seguridad básicas pasarón sin vulnerabilidades HIGH
✓ Producto Owner validó los criterios de aceptación
✓ Demo completada en la Sprint Review
✓ Preparación para release completada (versionado, changelog)

Este ejemplo muestra cómo cada criterio es medible y verificable. La diferencia entre "código escrito" y "código con pruebas unitarias al 85%" es la diferencia entre trabajo que genera deuda técnica y trabajo que construye calidad.

La DoD y el incremento del producto

En Scrum, el incremento es la suma de todos los elementos del Product Backlog completados durante un Sprint más todos los incrementos anteriores. El concepto de incremento está íntimamente ligado con la DoD porque:

Cada incremento debe cumplir la DoD: No basta con que una historia de usuario esté "hecha" si viola los estándares de calidad del equipo.
Los incrementos son acumulativos: El incremento actual se construye sobre los anteriores, por lo que la calidad de cada Sprint afecta a todos los Sprints futuros.
El incremento debe ser "potencialmente liberable": Gracias a la DoD, el equipo puede entregar el incremento al final de cada Sprint con confianza.

Un equipo sin DoD puede terminar un Sprint con historias de usuario "completadas" pero que en realidad requieren trabajo adicional antes de poder ser liberadas. Esto crea lo que se conoce como "feature freeze" al final del proyecto, donde todo parece hecho pero nada puede salir a producción.

Evolución de la Definition of Done

La DoD no es estática. Debe evolucionar con el equipo y el producto. Un equipo que inicia puede tener una DoD simple:

Sprint 1-3 (DoD básica):
✓ Código entregado
✓ Pruebas unitarias escritas
✓ Revisión por pares

Y evolucionar gradualmente:

Sprint 6-10 (DoD mejorada):
✓ Código entregado con CI/CD pasando
✓ Cobertura mínima 70%
✓ Code review con aprobaciones
✓ Pruebas de integración

Sprint 12+ (DoD madura):
✓ Código entregado con CI/CD pasando al 100%
✓ Cobertura mínima 85%, sin cobertura regresada
✓ Code review con 2+ aprobaciones
✓ Análisis estático limpio
✓ Pruebas E2E automatizadas
✓ Documentación actualizada
✓ Preparación para release

Errores comunes al implementar la Definition of Done

Error 1: Hacer la DoD demasiado compleja desde el inicio

Muchos equipos cometen el error de crear una DoD exhaustiva que incluye decenas de criterios desde el primer Sprint. Esto genera resistencia al cambio y hace que la DoD no se cumpla, destruyendo su credibilidad. La DoD debe comenzar simple y crecer incrementalmente.

Error 2: No hacer cumplir la DoD de forma consistente

Tener una DoD escrita pero no aplicarla erode la confianza del equipo. Si el equipo acepta "completar" historias sin cumplir todos los criterios "por esta vez", la DoD deja de tener valor. La DoD debe ser un muro infranqueable, no una guía sugerente.

Error 3: Confundir la DoD con los criterios de aceptación

Los criterios de aceptación definen qué debe hacer una funcionalidad específica, mientras que la DoD define cómo debe estar hecho todo el trabajo. Usarlos indistintamente genera confusión y trabajo incompleto. La DoD no sustituye a los criterios de aceptación ni viceversa.

Checklist de dominio

He explicado a mi equipo qué es la Definition of Done y por qué es importante
Mi equipo tiene una DoD escrita, visible y accesible para todos
La DoD incluye criterios verificables y medibles (no subjetivos)
Todos los miembros del equipo conocen y entienden cada criterio de la DoD
La DoD se aplica siempre, sin excepciones ni excusas
La DoD evoluciona activamente basándose en las necesidades del equipo
Las historias de usuario no se marcan como completadas sin cumplir la DoD
La DoD es un tema recurrente en las retrospectivas del Sprint
El Product Owner entiende que "Done" significa cumplir la DoD completa
Nuestro incremento al final de cada Sprint es potencialmente liberable