ScrumScrum · Calidad16 may 20215 min de lectura

Definición de Done y Criterio de Aceptación en Scrum: diferencias y uso conjunto

Son dos conceptos que el equipo confunde con frecuencia. La Definición de Done aplica al Incremento completo; el Criterio de Aceptación aplica a cada historia individual. Aquí está la diferencia que importa.

La confusión entre la Definición de Done y el Criterio de Aceptación es uno de los malentendidos más comunes en equipos Scrum. Ambos son herramientas de calidad, pero operan a niveles distintos y tienen propósitos distintos.

01¿Qué es la Definición de Done?

La Guía Scrum 2020 la define como "la descripción formal del estado del Incremento cuando cumple las medidas de calidad requeridas". Es una lista de condiciones globales que todo incremento debe cumplir para ser considerado potencialmente entregable.

La DoD se aplica a todo el Incremento, no a una historia concreta. Puede incluir condiciones como: código revisado por pares, pruebas unitarias al 80%, documentación actualizada, pruebas de rendimiento superadas. No es negociable por historia — aplica a todas sin excepción.

Error frecuenteConfundir la DoD con las pruebas funcionales. Las prácticas ágiles como la Integración Continua recomiendan verificar tanto pruebas técnicas como funcionales de forma continua, no solo al final del Sprint.

02¿Qué es el Criterio de Aceptación?

El Criterio de Aceptación define las condiciones específicas que debe cumplir cada funcionalidad concreta respecto a comportamiento y calidad técnica. Se define colaborativamente durante el refinamiento, antes de que la historia entre en el Sprint.

Importante: el Criterio de Aceptación no es estándar Scrum — no aparece en la Guía Scrum. Es una práctica complementaria que el equipo adopta para clarificar expectativas. Se define en colaboración entre Product Owner, Developers y Stakeholders.

03¿Cómo se usan conjuntamente?

El Criterio de Aceptación guía la implementación de cada historia y facilita las estimaciones. Actúa como un "contrato básico" que explicita las expectativas sin comprometer la flexibilidad de la solución técnica.

Un buen Criterio de Aceptación:

  1. Describe el resultado esperado por el cliente, no especificaciones técnicas.
  2. Usa formato: "[Tiene que / Debe de] + Verbo infinitivo + Descripción".
  3. Puede referenciar documentos de reglas de negocio cuando la lógica es compleja.
  4. Es verificable — alguien puede decir con certeza si se cumple o no.
Distinción claveLa DoD permanece estable durante el Sprint (solo se modifica en retrospectivas). El Criterio de Aceptación puede cambiar por consenso durante el Sprint si aparece nueva información relevante.