Criterios de aceptación
Los criterios de aceptación definen qué requisitos mínimos debe cumplir una historia de usuario para determinar que ésta funciona adecuadamente. A diferencia de la definición de hecho, los criterios de aceptación se centran en cada elemento de la pila del producto por separado.
Características
- Suelen presentarse en formato de lista o flujo.
- Pueden escribirse en lenguaje natural, tal y como el product owner o el miembro del equipo que sugiera cada criterio se exprese. Lo importante es que ayuden a recordar de forma breve y clara la intención detrás de cada criterio.
- Aunque el product owner puede haber ido preparando estos criterios con antelación, se concretan en equipo durante la reunión de planificación del sprint. Ya que ayudan a entender lo que el cliente espera conseguir con ese incremento y con cada historia que forma parte de él.
- Es responsabilidad del propietario del producto asegurarse de que los criterios de aceptación cubren todos los aspectos necesarios para que el equipo estime y desarrolle las historias adecuadamente.
- Cuando llegue la revisión del sprint, el product owner comprobará si cada una de las historias de usuario se puede aceptar en función a los criterios que se definieron.
Elementos
- el número de escenario;
- el título, donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”;
- el contexto, o sea las condiciones que desencadenan el escenario, y que se expresan con «Dado que»;
- el evento, es decir, la acción que el usuario ejecuta en el contexto definido para el escenario. Nos referimos a él usando «Cuando»;
- y el resultado o comportamiento esperado, que es el comportamiento del sistema en esa situación. Y que se expresa con «Entonces».
Cómo se redactan
Pueden escribirse tal como el propietario del producto se expresa, y pueden tener distintos formatos. El formato que empleemos dependerá de factores como las preferencias del equipo y el product owner.
Una manera popular de redactarlos es mediante BDD (Behavior Driven Development) y gherkin.
- BDD (Behavior Driven Development) es un enfoque de desarrollo de software que se centra en la comprensión de los comportamientos esperados de un sistema a través de la escritura de escenarios de usuario. Se basa en la colaboración entre desarrolladores, técnicos y stakeholders para definir claramente los requisitos y asegurarse de que el software cumpla con ellos.
- Gherkin es un lenguaje creado para las descripciones de comportamiento de software. Se utiliza en BDD para describir escenarios en un formato fácilmente legible y comprensible tanto para los desarrolladores como para los no técnicos.
Ejemplo
Historia de usuario: Como cliente, quiero tener la capacidad de realizar una búsqueda avanzada de productos en la tienda en línea para encontrar fácilmente lo que estoy buscando.
Escenario 1: Búsqueda por nombre de producto
Dado que un cliente ha accedido a la tienda en línea. Cuando el cliente quiere buscar un producto por su nombre. Entonces el cliente debería ver un campo de búsqueda en la página principal claramente visible. Y el cliente debería poder ingresar el nombre del producto que busca en el campo de búsqueda. Y al presionar "Buscar", el cliente debería ver una lista de productos que coincidan con el nombre proporcionado.
Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.
Escenario 2: Búsqueda por categoría de producto
Dado que un cliente ha accedido a la tienda en línea. Cuando el cliente quiere filtrar los productos por categoría. Entonces el cliente debería poder seleccionar una categoría de una lista desplegable de categorías disponibles. Y al seleccionar una categoría y hacer clic en "Buscar", el cliente debería ver una lista de productos que pertenecen a la categoría seleccionada.
Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.