Definición de Criterios de Listo vs Aceptación en Scrum

La  definición de finalización  (DoD) es una lista de requisitos que debe cumplir la historia de usuario para que el equipo pueda invocarla como completa.

Los  criterios de aceptación  de las historias de usuario incluyen un conjunto de escenarios de prueba que cumplirán los requisitos para confirmar si el software funciona como se espera.

¿Cuándo se completará la historia de usuario?

En otras palabras, para completar las historias de usuario, se deben cumplir los criterios de aceptación y DOD. Los incrementos de productos no se consideran completos a menos que ambas listas estén completas. Por lo tanto, necesitamos definir dos aspectos de la definición del Departamento de Defensa: criterios de finalización y criterios de aceptación:

Definición de hecho

La definición de Listo está estructurada como una lista de elementos, cada uno de los cuales se usa para validar una Historia o PBI, que existe para garantizar que el Equipo de desarrollo esté de acuerdo con la calidad del trabajo que está intentando producir. Sirve como una lista de verificación que se utiliza para verificar que  cada elemento  de la cartera de productos  (también conocido como PBI) o historia de usuario esté completo. Los elementos en la definición de «Terminado» están destinados a ser aplicables a todos los elementos en la Lista de Producto, no solo a una sola Historia de Usuario.

Se puede resumir de la siguiente manera:

• El término se aplica más al incremento del producto como un todo
• En la mayoría de los casos, el término implica que el incremento del producto se puede enviar
• El término se define en la Guía Scrum
• Se utiliza como una forma de comunicación entre los miembros del equipo.
• Calidad general del software
• Si el incremento se puede enviar o no

Ejemplo — Definición de Listo

• ¿Código revisado por pares?
• ¿Código completado?
• ¿Código revisado?
• ¿Código registrado?
• ¿Pruebas unitarias aprobadas?
• ¿Pruebas funcionales superadas?
• ¿Pruebas de aceptación completadas?
• ¿ Propietario del producto  revisado y aceptado?

Criterios de aceptación

Las historias de usuario son uno de los principales  artefactos de desarrollo  para  el desarrollo ágil , pero  Scrum  no requiere explícitamente el uso de Historias de usuario o Criterios de aceptación. Si se considera que un elemento de la cartera de productos es demasiado grande para incluirlo en un sprint, normalmente se dividirá en una historia de usuario y, posteriormente, en un conjunto de tareas, como se muestra en la figura:

Las historias de usuarios encapsulan los criterios de aceptación, por lo que a menudo vemos que la definición de hecho y los criterios de aceptación coexisten en nuestro proceso de desarrollo de scrum. La historia de usuario proporciona el contexto de la funcionalidad que el equipo debe ofrecer. Los criterios de aceptación brindan orientación sobre los detalles de dicha funcionalidad y cómo los aceptará el cliente. Los dos juntos proporcionan el entregable completo.

Algunos de los Criterios de aceptación se descubrirán en los eventos de Refinamiento de la acumulación en curso antes de que comience el Sprint, y otros se descubrirán justo después  de la Planificación del Sprint  cuando se siente a conversar sobre la historia del usuario en un equipo pequeño. Por lo tanto, los criterios de aceptación son atributos que son únicos para la historia de usuario o el elemento de la cartera de productos.

• El término se aplica a un PBI/Historia individual
• Los Criterios de Aceptación son diferentes para cada PBI/Historia
• El término no está definido en la Guía Scrum
• Se utiliza como una forma de comunicar a todos los involucrados que se han cumplido los requisitos para una PBI/historia en particular
• También conocidas como pruebas de aceptación, condiciones de satisfacción, en algunos casos «casos de prueba», etc.

Ejemplo de Historia de Usuario con Criterios de Aceptación

La siguiente figura muestra un ejemplo de criterios de aceptación de una historia de usuario.