¿Cuál es la diferencia entre la historia de usuario y los criterios de aceptación?

Table of Contents hide

2 Los objetivos de la definición de hecho

3.1 Por ejemplo, en la industria del software, los equipos pueden necesitar hacer algunas de las siguientes preguntas para llegar a su DoD:

4 Criterios de aceptación

5 Los objetivos de los criterios de aceptación

6 Ejemplo: Criterios de aceptación

7 Ejemplo de Historia de Usuario con Criterios de Aceptación

La definición de Listo (DoD) es una lista de requisitos que debe cumplir una historia de usuario para que el equipo la considere completa. Mientras que los criterios de aceptación de una historia de usuario consisten en un conjunto de escenarios de prueba que se deben cumplir para confirmar que el software funciona como se esperaba.

La diferencia entre estos dos es que el DoD es común para todas las Historias de usuario, mientras que los Criterios de aceptación se aplican a Historias de usuario específicas . Los criterios de aceptación de cada historia de usuario serán diferentes según los requisitos de esa historia de usuario.

En otras palabras, tanto el DoD como los criterios de aceptación deben cumplirse para completar la historia de usuario. El incremento del producto no se considera completo, a menos que se completen estas dos listas. Por lo tanto, necesitamos definir dos aspectos de la Definición de Listo (DOD): 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

Los objetivos de la definición de hecho

Construya un entendimiento común dentro del equipo sobre la calidad y la integridad
Úselo como una lista de verificación con la que se comparan las Historias de usuario (o PBI)
Asegúrese de que el incremento enviado al final del Sprint tenga alta calidad y que todos los involucrados entiendan bien la calidad.

Ejemplo — Definición de Listo

Por ejemplo, en la industria del software, los equipos pueden necesitar hacer algunas de las siguientes preguntas para llegar a su DoD:

¿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.

Los objetivos de los criterios de aceptación

Aclarar lo que el equipo debe construir antes de comenzar a trabajar
Asegúrese de que todos tengan una comprensión común del problema.
Ayude a los miembros del equipo a saber cuándo la Historia está completa
Ayude a verificar la Historia a través de pruebas automatizadas.

Ejemplo: Criterios de aceptación

Un usuario no puede enviar un formulario sin completar todos los campos obligatorios
La información del formulario se almacena en la base de datos de registros.
El pago se puede realizar mediante tarjeta de crédito.
Se envía un correo electrónico de confirmación al usuario después de enviar el formulario

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.

Referencias