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.

Véase también

• Historia de usuario.
• Definición de hecho.
• Pila del producto.
• Product owner.
• Scrum Manager Blog: «Criterios de aceptación: ejemplos para elaborarlos».
• Scrum Manager Podcast | Episodio 6: Definition of Done.
• Scrum Manager Blog: Transcripción Scrum Manager Podcast | Episodio 6: Definition of Done.