Criterios de aceptación y definición de terminado en Scrum

Una entrega con calidad y valor nace del refinamiento, la estimación y la preparación rigurosa de las historias de usuario. La claridad sobre criterios de aceptación y definición de terminado evita ambigüedad, reduce incertidumbre y asegura que solo se presente en sprint review lo que realmente cumple el estándar esperado.

¿Qué diferencia a criterios de aceptación y definición de terminado?

Los criterios de aceptación son condiciones específicas que permiten verificar si una historia está completamente lista y desarrollada. Son únicos por historia: describen qué se espera exactamente del comportamiento o resultado.

La definición de terminado (Definition of Done) es un criterio de calidad transversal a todo el incremento. Actúa como un estándar formal: si una historia no lo cumple, no puede presentarse en el sprint review. Este enfoque fomenta disciplina técnica y consistencia.

Habilidades clave que se ejercitan: refinamiento del backlog para aclarar alcance, estimación para dimensionar esfuerzo y verificación sistemática contra criterios. Todo con foco en calidad y valor del producto.

¿Cómo redactar y validar criterios de aceptación en historias de usuario?

Para una app de aprendizaje de idiomas, se plantea listar verbos para que la persona usuaria aprenda significado y pronunciación. Ejemplos de criterios de aceptación que ilustran claridad y comprobabilidad:

• Mostrar una lista de 100 verbos irregulares más comunes.
• Incluir para cada verbo: presente, pasado simple y pasado participio.
• Permitir ordenar alfabéticamente la lista.
• Hacer visible la lista en la pantalla principal.

Estos criterios orientan el desarrollo y la prueba funcional. Al ser medibles, facilitan la validación por parte del equipo y de las partes interesadas. Además, sirven para diseñar casos de prueba claros y evitar interpretaciones distintas dentro del equipo.

¿Qué incluye una buena definición de terminado para el sprint review?

La definición de terminado eleva el estándar técnico y de producto, garantizando que cada historia se integre con calidad al incremento. Componentes típicos que deben cumplirse para todas las historias:

• Pasar todas las pruebas de calidad automatizadas. Asegura no regresiones y comportamiento esperado.
• Completar revisión de código por otra persona del equipo. Mejora legibilidad y detecta defectos.
• Estar desplegada en un entorno de pruebas. Valida integración y operatividad.
• Contar con documentación adecuada. Facilita mantenimiento y conocimiento compartido.

Cuando una historia satisface sus criterios de aceptación y cumple la definición de terminado, el incremento resultante es más confiable, mantenible y listo para mostrar con confianza en el sprint review.

¿Tú cómo definirías los criterios de aceptación de tus historias y tu primera versión de definición de terminado? Comparte tus ideas en los comentarios.