Definition of Done: cómo definir cuándo una tarea está completa

La Definition of Done (DoD) es un compromiso del equipo que describe el estado de calidad que debe cumplir cada elemento del Product Backlog antes de considerarse completado. Sin una DoD clara, cada miembro del equipo podría tener una idea diferente de lo que significa "terminado".

¿Por qué es importante la Definition of Done?

Imagina que en tu equipo, para el desarrollador A "terminado" significa que el código compila, mientras que para la desarrolladora B significa que además está desplegado en producción y verificado por el Product Owner. Esta discrepancia genera malentendidos, retrabajo y, lo peor de todo, la falsa sensación de que el equipo avanza cuando en realidad acumula deuda técnica.

La DoD elimina esa ambigüedad y aporta beneficios concretos:

• Elimina la ambigüedad sobre qué significa "completado" para todos los miembros del equipo
• Asegura un nivel de calidad consistente en cada Incremento, independientemente de quién lo desarrolle
• Facilita la transparencia entre el equipo y los stakeholders, que saben exactamente qué esperar
• Previene la acumulación de deuda técnica al establecer estándares mínimos que no se negocian
• Hace predecible la calidad de las entregas, lo que genera confianza en el equipo y en la organización

Según el informe Chaos Report del Standish Group, los proyectos que carecen de criterios de calidad claros tienen un 45 % más de probabilidades de exceder su presupuesto original. La DoD es precisamente ese criterio de calidad que evita que los proyectos se desvíen.

Cómo crear una Definition of Done efectiva

La DoD debe ser creada por el equipo, no impuesta externamente. Cuando la gerencia dicta una DoD sin consultar a los desarrolladores, el equipo suele ignorarla o cumplirla solo en apariencia. La clave está en que el equipo sienta la DoD como propia.

El taller de creación

Te recomiendo este proceso paso a paso:

1. Reúne al equipo completo en una sesión de una hora. Incluye a todos los Developers, al Scrum Master y al Product Owner.
2. Pregunta: ¿qué significa para ti que algo está terminado? Cada persona escribe sus criterios en notas adhesivas.
3. Agrupa los criterios por categorías: código, pruebas, documentación, despliegue, verificación.
4. Debate los criterios controvertidos. ¿Es necesario tener cobertura de pruebas del 80 % o basta con el 60 %? ¿El despliegue en producción es parte del "Done" o es un paso separado de release?
5. Vota. Los criterios que obtengan consenso pasan a la DoD. Los que no, se discuten hasta encontrar un punto medio.
6. Documenta la DoD y colócala en un lugar visible del espacio de trabajo del equipo.

DoD básica (para un equipo que empieza)

• [ ] Código escrito y revisado por al menos un par (pair review)
• [ ] Pruebas unitarias pasan con cobertura mínima del 80 %
• [ ] Integración con CI/CD exitosa sin errores
• [ ] Documentación actualizada si aplica (README, comentarios, wiki)
• [ ] Desplegado en entorno de staging y verificado visualmente
• [ ] Product Owner ha revisado y aceptado la historia

DoD avanzada (para equipos maduros)

• [ ] Pruebas de integración automatizadas ejecutadas y pasadas
• [ ] Pruebas de rendimiento sin regresiones respecto al promedio histórico
• [ ] Auditoría de seguridad básica: sin vulnerabilidades críticas o altas
• [ ] Actualización de la documentación de API si el elemento la modifica
• [ ] Verificación de accesibilidad (criterios WCAG 2.1 nivel AA)
• [ ] Pruebas de humo en producción o entorno pre-productivo
• [ ] Métricas de uso registradas para validación post-lanzamiento

¿Cuándo se actualiza la DoD?

La DoD no es estática. El equipo debe revisarla en la retrospectiva al menos una vez al trimestre. Si el equipo ha madurado o el contexto del proyecto ha cambiado, la DoD debe evolucionar. Por ejemplo, un equipo que empieza a trabajar con microservicios puede necesitar añadir criterios de contratos de API o pruebas de caos.

Definition of Done vs Criterios de Aceptación

Una de las confusiones más comunes en los equipos Scrum es mezclar la Definition of Done con los criterios de aceptación. Son complementarios pero distintos:

Aspecto	Definition of Done	Criterios de Aceptación
Ámbito	Aplica a todos los elementos del backlog sin excepción	Específicos para cada historia de usuario
Naturaleza	Define la calidad técnica mínima	Define el comportamiento funcional esperado
Estabilidad	Es estable y cambia lentamente	Varía para cada historia
Responsable	El equipo completo (Developers)	El Product Owner (con input del equipo)
Momento de definición	Al inicio del proyecto o trimestre	Durante el refinamiento o Sprint Planning
Ejemplo	"Cobertura de pruebas > 80 %"	"El usuario recibe un email de confirmación al registrarse"

Una historia puede cumplir todos sus criterios de aceptación pero no estar "Done" si no pasa la DoD. Por ejemplo, el desarrollador implementó el registro con email de confirmación (criterio de aceptación cumplido), pero olvidó escribir las pruebas unitarias (DoD incumplida). En ese caso, la historia no se considera completa.

Errores comunes al implementar la DoD

He visto equipos cometer estos errores una y otra vez. Te recomiendo revisarlos en tu retrospectiva para asegurarte de que no caes en ellos:

1. DoD demasiado larga

Una DoD con 20 criterios es imposible de cumplir. El equipo terminará ignorándola o marcando casillas sin sentido. Empieza con 5-7 criterios esenciales y ve añadiendo conforme el equipo madure.

2. DoD sin verificación objetiva

Si un criterio dice "código limpio", ¿quién decide si está limpio? Cada criterio debe ser verificable de forma objetiva. En lugar de "código de calidad", usa "el código pasa el linter sin errores y tiene revisión de par".

3. DoD que cambia en medio del Sprint

Si durante el Sprint el equipo descubre que falta un criterio, no lo añadas a la DoD hasta el siguiente Sprint. Cambiar las reglas del juego en medio de una iteración rompe el compromiso y desmotiva al equipo.

4. El PO usa la DoD como herramienta de presión

"He visto Product Owners que dicen: 'si la historia no está Done, no la contamos en la Sprint Review'. La DoD es un compromiso del equipo, no una cláusula penal. Si el equipo necesita flexibilidad para ciertos elementos, se negocia, no se impone."

5. No actualizar la DoD cuando el equipo madura

Un equipo que nunca revisa su DoD probablemente se ha estancado. Si seguís aplicando los mismos criterios que hace un año, os estáis perdiendo oportunidades de mejorar la calidad.

Datos del sector sobre calidad y DoD

Según el informe de Tricentis sobre automatización de pruebas, las organizaciones que aplican una DoD estricta reducen los defectos en producción en un 38 % en promedio. Además, el State of Engineering Report de LinearB indica que los equipos con DoD explícita tienen un cycle time 25 % más corto, porque dedican menos tiempo a retrabajo y correcciones de última hora.

Un dato que siempre comparto con los equipos que entreno: el coste de corregir un defecto en producción es 15 veces mayor que corregirlo durante el desarrollo, según el estudio clásico de IBM Systems Sciences Institute. La DoD es precisamente la barrera que evita que esos defectos lleguen a producción.

Ejemplo práctico: el caso de "casi terminado"

María es desarrolladora en un equipo que no tenía DoD. Terminó su historia de "carrito de compras" a las 5 de la tarde del último día del Sprint. El código compilaba y la funcionalidad se veía bien en su máquina. Sin embargo:

• No había pruebas unitarias
• No se había ejecutado la suite de integración
• El código no había sido revisado por ningún compañero
• La documentación del endpoint no se había actualizado

En la Sprint Review, el PO vio la demo y aceptó la historia. Pero al día siguiente, el equipo de QA encontró que el carrito no funcionaba en el navegador Safari y que el endpoint devolvía un error 500 cuando se añadían más de 10 productos. María tuvo que dedicar dos días del siguiente Sprint a corregir estos defectos.

Si el equipo hubiera tenido una DoD clara, María habría sabido desde el día uno que necesitaba pruebas, code review y verificación en staging. La historia no se habría aceptado hasta cumplir todos los criterios, y los defectos se habrían detectado antes.

Cómo hacer cumplir la DoD sin burocracia

La DoD no debe convertirse en un checklist burocrático. Para mantenerla útil:

• Integra la DoD en el flujo de trabajo. Si usas Jira, crea un checklist de la DoD en la transición a "Done". Si usas GitHub, usa las acciones de PR para verificar automáticamente los criterios técnicos.
• Revisa la DoD en cada Daily Scrum. No hace falta leerla entera, pero el equipo puede preguntarse: "¿qué criterios de la DoD hemos cumplido hoy?"
• Usa la DoD en la Sprint Review. Cuando el PO revisa una historia, el equipo confirma que cumple la DoD antes de darla por terminada.
• Celebra cuando se cumple. Si el equipo completa un Sprint con todas las historias cumpliendo la DoD, es motivo de celebración. Refuerza el hábito.

Mi recomendación personal

Llevo varios años trabajando con equipos Scrum y he visto que la DoD es uno de los artefactos más infravalorados. Muchos equipos se saltan su definición porque "ya saben lo que significa terminar". Y luego pagan las consecuencias en forma de defectos, retrabajo y Sprint Goals incumplidos.

Mi consejo: dedica una retrospectiva entera a definir o revisar tu DoD. No es tiempo perdido. Es una inversión que se amortiza la primera vez que el equipo evita un bug en producción porque la DoD lo detectó a tiempo. La DoD es la red de seguridad de la calidad en equipos ágiles.

Conclusión

La Definition of Done es mucho más que un checklist. Es el contrato de calidad que el equipo hace consigo mismo. Sin ella, cada miembro del equipo trabaja con estándares distintos y la calidad se vuelve inconsistente. Con una DoD clara, compartida y verificable, el equipo entrega Incrementos realmente terminados, con calidad predecible y sin sorpresas desagradables en producción.