Definición de Hecho frente a Criterios de Aceptación en Scrum – Guía Completa

Definición de Hecho (DoD) es una lista de verificación de requisitos que una historia de usuario debe cumplir para que el equipo la considere completa. Mientras que el criterios de aceptación de una historia de usuario incluye un conjunto de casos de prueba que deben cumplirse para confirmar que el software funciona según lo previsto.

La diferencia clave radica en que el DoD es común a todas las historias de usuario, mientras que los criterios de aceptación son específicos para cada historia de usuario. Los criterios de aceptación para cada historia de usuario variarán según los requisitos específicos de esa historia.

En otras palabras, tanto la Definición de Hecho como los criterios de aceptación deben cumplirse para que una historia de usuario se considere completa. El incremento del producto no se considera completo a menos que ambas listas de verificación se cumplan completamente. Por lo tanto, debemos definir dos aspectos de la Definición de Hecho: el DoD y los criterios de aceptación:

Definición de Hecho frente a Criterios de Aceptación

Definición de Hecho:

La Definición de Hecho está estructurada como una lista de verificación, con cada elemento sirviendo como punto de verificación para una historia o PBI. Su propósito es garantizar que el equipo de desarrollo esté de acuerdo sobre la calidad del trabajo que está entregando. Actúa como una lista de verificación para verificar la completitud de cada Backlog del Productoelemento (también conocido como PBI o historia de usuario). Los elementos de la Definición de Hecho están pensados para aplicarse a todos los elementos del Backlog del Producto, no solo a historias de usuario individuales. Puede resumirse como sigue:

• Aplica al incremento completo del producto
• Implica que el incremento del producto es potencialmente entregable en la mayoría de los casos
• Definido en la Guía de Scrum
• Sirve como herramienta de comunicación entre los miembros del equipo:
  • Calidad general del software
  • Si el incremento es entregable

Objetivos de la Definición de Hecho

• Establecer un entendimiento compartido sobre la calidad y la completitud entre el equipo
• Actuar como una lista de verificación para verificar historias de usuario (o PBIs)
• Garantizar que el incremento producido al final de un Sprint sea de alta calidad y que todos los participantes entiendan claramente los estándares de calidad

Ejemplo – Definición de Hecho

Por ejemplo, en la industria del software, los equipos pueden hacerse las siguientes preguntas para definir su DoD:

• ¿Código revisado por pares?
• ¿Código completado?
• ¿Código revisado?
• ¿Código verificado?
• ¿Pruebas unitarias aprobadas?
• ¿Pruebas funcionales aprobadas?
• ¿Pruebas de aceptación completadas?
• El dueño del producto ha revisado y aceptado

Criterios de aceptación

Una historia de usuario es uno de los artefactos clave en desarrollo ágil, pero Scrum no requiere explícitamente el uso de historias de usuario o criterios de aceptación. Si un elemento de la lista de productos es demasiado grande para encajar en un Sprint, generalmente se descompone en historias de usuario y luego en un conjunto de tareas, como se muestra a continuación:

Criterios de aceptación

Las historias de usuario incluyen los criterios de aceptación, por lo que a menudo vemos que la Definición de Terminado y los criterios de aceptación coexisten en nuestros procesos de Scrum. La historia de usuario proporciona el contexto sobre la funcionalidad que el equipo debe entregar. Los criterios de aceptación ofrecen orientación detallada sobre lo que debe hacer la característica y cómo el cliente la aceptará. Juntos definen el entregable completo.

Algunos criterios de aceptación se descubren durante la sesión continua de refinamiento de la lista de productos antes de que comience el Sprint, mientras que otros se identifican inmediatamente después de Planificación del Sprint, para que el equipo pueda tener una conversación con la historia de usuario. Por lo tanto, los criterios de aceptación son un atributo único de una historia de usuario o elemento de la lista de productos.

• Aplica a cada PBI/historia individual
• Los criterios de aceptación varían según el PBI/historia
• No definido en la Guía de Scrum
• Sirve como herramienta de comunicación para cumplir con los requisitos específicos de un PBI/historia
• También conocido como pruebas de aceptación, condiciones de satisfacción, o en algunos casos “casos de prueba”

Objetivos de los criterios de aceptación

• Aclarar lo que el equipo debe establecer antes de comenzar el trabajo
• Garantizar que todos compartan una comprensión común de los requisitos
• Ayudar a los miembros del equipo a entender cuándo una historia está completa
• Ayudar a verificar la historia mediante pruebas automatizadas

Ejemplo – Criterios de aceptación

• El usuario no puede enviar el formulario sin completar todos los campos obligatorios
• La información del formulario se almacena en la base de datos de registro
• Los huéspedes pueden pagar mediante tarjeta de crédito
• Se envía un correo de confirmación al usuario después de enviar el formulario

Ejemplo de una historia de usuario con criterios de aceptación

La imagen de abajo muestra un ejemplo de criterios de aceptación para una historia de usuario.

Ejemplo de definición de terminado