¿Tu equipo termina el Sprint diciendo que algo está «listo» y dos días después aparecen bugs, falta documentación o el código no pasa los tests en producción? Si la respuesta es sí, el problema no es el equipo. Es que no existe un acuerdo real sobre qué significa «listo». La Definition of Done no es un formulario que se rellena una vez y se olvida. Es el contrato técnico más importante que un equipo de desarrollo puede tener. Y la diferencia entre una DoD bien construida y una superficial es exactamente la diferencia entre un equipo que entrega valor real cada Sprint y uno que acumula deuda técnica sprint a sprint hasta que el sistema colapsa.
Por qué la DoD es un problema técnico, no un problema de proceso
Muchos equipos tratan la Definition of Done como un elemento administrativo de Scrum. Una lista que hay que tener porque el framework lo pide. Error.
La DoD es una declaración de calidad técnica. Define el nivel mínimo que debe alcanzar cada incremento para ser considerado potencialmente entregable. Cuando está bien construida, protege al equipo de tres problemas que destruyen la velocidad a medio plazo:
- Deuda técnica invisible: trabajo que parece terminado pero que esconde problemas que alguien tendrá que resolver después, con mayor coste.
- Retrabajo sistemático: historias que vuelven al Backlog porque en producción no funcionan como se esperaba.
- Pérdida de confianza: stakeholders que dejan de creer en las estimaciones del equipo porque «listo» nunca significa lo mismo dos veces.
Una DoD técnica sólida convierte el Sprint en un ciclo de entrega predecible. Sin ella, Scrum es solo una forma de organizar el caos.
Cómo construir una DoD técnica que funcione de verdad
Una DoD efectiva no se copia de internet ni se importa de otro equipo. Se construye con el equipo, a partir de su contexto técnico real. Aquí está el proceso práctico:
Punto de partida: la retrospectiva técnica
El mejor momento para construir o revisar la DoD es una retrospectiva enfocada en calidad. La pregunta que abre la conversación es directa: ¿Qué tendría que ser verdad sobre nuestro código para que pudiéramos desplegarlo en producción ahora mismo sin miedo?
Las respuestas de esa conversación son la base de la DoD.
Criterios técnicos que no pueden faltar
Una DoD técnica madura incluye, como mínimo:
- Código revisado por al menos un miembro del equipo distinto al autor
- Tests unitarios escritos y pasando con cobertura acordada por el equipo
- Tests de integración ejecutados sin errores
- Pipeline de CI/CD completado en verde
- Deuda técnica identificada y registrada en el Backlog si no se resuelve en el Sprint
- Documentación técnica actualizada donde sea necesario
- Despliegue en entorno de staging completado y validado
La DoD evoluciona con el equipo
Un equipo que empieza con Scrum no puede tener la misma DoD que un equipo maduro. Lo importante es que cada Sprint el equipo sea capaz de cumplirla de forma consistente y que, en las retrospectivas, se evalúe si es momento de elevar el estándar.
Los antipatrones que convierten la DoD en papel mojado
Tener una DoD escrita no garantiza nada. Estos son los errores más frecuentes:
DoD negociable bajo presión
Es el antipatrón más destructivo. El Sprint está terminando, hay historias sin completar y alguien propone «relajar» la DoD para poder cerrar el Sprint. Cada vez que esto ocurre, el equipo aprende que la DoD es opcional cuando hay presión. Y la presión siempre vuelve.
La solución no es ser inflexible. Es dimensionar mejor el Sprint desde el Planning para no llegar a esa situación. Si una historia no cumple la DoD, no está Done. Punto.
DoD genérica que no refleja el stack técnico del equipo
Una lista copiada de un blog que incluye criterios que el equipo no puede medir ni verificar no sirve de nada. Si el equipo trabaja con microservicios, la DoD debe reflejar eso. Si el producto tiene requisitos de accesibilidad, deben estar en la DoD.
DoD que solo conoce el Scrum Master
Si los desarrolladores no han participado en construirla y no la tienen interiorizada, no es un acuerdo de equipo. Es una norma impuesta que nadie va a cumplir con convicción.
No revisar la DoD periódicamente
Una DoD que no evoluciona es una DoD que se queda obsoleta. El equipo crece, las herramientas cambian, el producto madura. La DoD debe reflejar ese crecimiento.
Conclusión: la DoD es el espejo de la madurez técnica del equipo
Un equipo que tiene una Definition of Done técnica sólida, la cumple de forma consistente y la evoluciona con cada retrospectiva está demostrando algo más que disciplina de proceso. Está demostrando que entiende que la calidad no es una fase al final del desarrollo. Es una responsabilidad continua que se ejerce en cada línea de código, en cada revisión y en cada decisión técnica del Sprint.
El próximo post entra en detalle en cómo gestionar la deuda técnica dentro de Scrum sin que destruya la velocidad del equipo ni la moral del equipo. Déjame en los comentarios cómo tiene construida tu DoD ahora mismo y qué criterio os costó más acordar.