Definición de Done y Criterio de Aceptación
Tiempo de lectura: 4 minutos
Son dos conceptos que se confunden con frecuencia, y esa confusión genera problemas reales de calidad. Uno es un estándar de Scrum; el otro, una buena práctica ágil que ni siquiera aparece en la Guía de Scrum. Entender la diferencia — y cómo se usan juntos — evita retrabajos y malentendidos entre Product Owner y Developers.
¿Qué es la Definición de Done?
La Guía Scrum 2020 define la Definición de Done como la descripción formal del estado del Incremento cuando cumple las medidas de calidad requeridas por el Producto. En el momento en que un ítem del Product Backlog cumple la Definición de Done, ha nacido un Incremento.
Esta definición se aplica a todo el Incremento, no a un ítem aislado, y detalla las condiciones bajo las cuales el producto es usable sin necesidad de añadir trabajo adicional. Es un estándar de Scrum: aparece explícitamente en la Guía y todo Equipo Scrum debe tener una.
¿Qué es el Criterio de Aceptación?
El Criterio de Aceptación es una buena práctica de ingeniería ágil que consiste en definir, antes de implementar, las condiciones específicas de comportamiento y calidad técnica de cada funcionalidad. Suele definirse durante el refinamiento previo al Sprint, de forma conjunta entre Product Owner, Developers y otros stakeholders relevantes (usuarios, expertos).
A diferencia de la Definición de Done, el Criterio de Aceptación no es estándar de Scrum — no aparece en la Guía — y no es un documento que el Product Owner escribe para que lo lean los Developers, sino algo que se define en conjunto para reducir malentendidos. Tampoco debe confundirse con las pruebas funcionales (que se ejecutan durante el desarrollo y pueden adoptar estilos como Behaviour-Driven Development): el Criterio de Aceptación guía la implementación y ayuda a estimar y detectar dependencias; las pruebas funcionales verifican después que esa implementación es correcta.
¿Cómo se usan juntos la Definición de Done y el Criterio de Aceptación?
El Criterio de Aceptación actúa como un "contrato" básico con el cliente para explicitar expectativas — sin que eso signifique renunciar a la flexibilidad durante la implementación o rechazar cambios que surjan sobre la marcha. Si durante el desarrollo aparecen dudas o nuevas ideas que lo modifiquen, debería consensuarse de nuevo con el Product Owner y los stakeholders.
La Definición de Done, en cambio, no cambia durante el Sprint — solo en retrospectivas, si el equipo decide mejorar su nivel de calidad. Una buena práctica como la Integración Continua ayuda a verificar a diario que ambos —criterio y definición— se cumplen, en lugar de descubrirlo todo al final del Sprint.
Si quieres profundizar en cómo escribir buenos criterios de aceptación dentro de historias de usuario, te puede interesar la guía definitiva para escribir buenas historias de usuario o cómo adaptar la Definición de Done al desarrollo con IA. Estos conceptos se trabajan en profundidad en nuestros cursos oficiales Professional Scrum Master y Professional Scrum Product Owner.