Cuando "Terminado" no significa nada: cómo dar fuerza a una Definition of Done débil
Sobre el papel, casi todos los Equipos Scrum tienen una Definition of Done. En la práctica, muchos menos tienen una que signifique algo. La Guía de Scrum es clara sobre por qué importa: la Definition of Done es el compromiso compartido y formal del equipo con la calidad. Cuando un Increment la cumple, es entregable. Cuando no, el trabajo no está Terminado — simplemente vuelve al Product Backlog. El problema es que muchos equipos tratan la Definition of Done como un cartel en la pared en lugar de la barrera que debería ser.
El costo de una débil rara vez se ve en un solo Sprint. Aparece más tarde: como una acumulación de funciones "terminadas" que aún hay que probar, deuda de integración que surge durante una entrega, o un Product Owner que en silencio deja de creer en la Sprint Review. Tras dieciocho meses de cadenas de suministro interrumpidas y equipos a medias en remoto, muchas organizaciones arrastraban justamente este tipo de retrabajo oculto, y solo lo notaron al intentar entregar.
Cómo se ablanda una Definition of Done
Describe actividades, no resultados. "Código escrito, pruebas escritas" dice qué hizo la gente, no si el resultado funciona. Una entrada útil es verificable: "las pruebas automatizadas pasan en el entorno de integración", no "escribimos pruebas".
Es aspiracional, no honesta. Los equipos listan lo que desearían hacer — regresión completa, análisis de seguridad, documentación — y luego se saltan la mitad en silencio bajo la presión de los plazos. Una Definition of Done que se incumple de forma rutinaria vale menos que una corta que de verdad se respeta.
Solo vive en la cabeza de los Developers. Si el Product Owner y los interesados no pueden decir qué significa Terminado, la Sprint Review se vuelve una negociación sobre si algo está realmente acabado. Ese debate debió resolverse antes de empezar el trabajo.
Se detiene en el límite del equipo. Cuando el despliegue, la accesibilidad o la migración de datos son cosa de "otra persona", el Increment no es realmente entregable. Los equipos híbridos y distribuidos lo sufren más, porque los traspasos son invisibles hasta que fallan.
Nunca cambia. Una Definition of Done fijada hace un año, antes de una nueva norma de cumplimiento o una nueva plataforma, está silenciosamente desactualizada. Debe evolucionar con la capacidad y el contexto del equipo.
Cómo devolverle la fuerza
La solución no es un documento más largo. Es uno más corto y más verdadero, que todo el equipo realmente haga cumplir. Empieza por redactar cada punto de modo que cualquiera pueda comprobarlo sin debate — pasa o falla, sin interpretación. Luego contrasta la lista con la realidad: en los últimos tres Sprints, ¿cada Increment que llamaste Terminado cumplía de verdad cada línea? Si no, cambia el comportamiento o cambia la línea, pero cierra la brecha.
Haz cada criterio observable y binario — se cumple o no, sin "casi".
Cubre todo el camino hasta lo entregable, incluidos los pasos que hoy llevan personas ajenas al equipo.
Revisa la Definition of Done en la Retrospectiva, no solo cuando algo se rompe.
Trata como no Terminado el trabajo que no la cumpla — devuélvelo al Product Backlog en vez de doblar la regla.
Mantenla visible y compartida, para que el Product Owner use el mismo listón que los Developers.
Una Definition of Done con fuerza cambia el tono de una Sprint Review. En vez de discutir si una función está acabada, el equipo demuestra un Increment en el que todos ya confían. Esa confianza es el verdadero entregable: permite al Product Owner pronosticar con honestidad y a los interesados planificar en torno a algo sólido. Para las organizaciones que aún desenredan los atrasos de la pandemia, esa fiabilidad vale más que otro arranque de producción.
Si tus equipos entregan trabajo que no deja de volver, la asesoría en entrega de programas y proyectos de XNM puede ayudarte a reconstruir un estándar de calidad en el que toda tu organización confíe de verdad.