Criterios de aceptación: ejemplos para elaborarlos

En Scrum Manager Podcast hablamos de la definición de «hecho» y sus diferencias con los criterios de aceptación. Ahora queremos aclarar mejor cómo se redactan estos criterios.

Si tenéis experiencia escribiendo tests y criterios, no dudéis en contarnos en los comentarios qué formatos habéis utilizado y si os parecen más o menos útiles.

Criterios de aceptación: qué son

Los criterios de aceptación nos hablan sobre cada elemento del backlog por separado. Nos indican cuándo una historia de usuario puede darse por finalizada. Suelen expresarse en forma de lista, como un flujo o una serie de criterios.

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. Quien mejor sabe cuáles son las expectativas del cliente es el propietario del producto, así que es responsabilidad suya 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. 

Cómo se redactan

Los criterios de aceptación pueden escribirse tal como el propietario del producto se expresa, y pueden tener distintos formatos. Es importante recalcar que no existe un único formato estándar. 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. 

• Y 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. 

Ejemplos

Nuestra empresa vende libros a través de su página web. Una de nuestras historias de usuario es: «Como cliente quiero poder explorar libros para poder escoger el que voy comprar».

Escenario 1: Exploración de libros

- Dado que un cliente ha accedido a la tienda online
- Cuando el cliente quiere explorar libros
- Entonces el cliente debería ver una lista de libros con los siguientes detalles:
    - título,
    - autor,
    - género
    - y precio.

Escenario 2: Filtrar libros por género

- Dado que un cliente ha accedido a la tienda online
- Cuando el cliente quiere filtrar los libros por género
- Entonces el cliente debería poder seleccionar un género de la lista
    - Y debería ver sólo los libros del género seleccionado

Como vemos, los elementos de los criterios de aceptación derivados de esta sintaxis son:

• 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». 

Tanto el contexto como el resultado pueden tener información adicional. Por ejemplo, en el segundo escenario, a «Entonces el cliente debería poder seleccionar un género de la lista» se le añade «Y debería ver solo libros del género seleccionado».

---

Estas no son las únicas formas de redactar criterios de aceptación. Además, los criterios de aceptación, se refieren a un elemento concreto del backlog y se relacionan con las historias de usuario. Suele ser recomendable que las historias de usuario incluyan estos criterios porque facilitan al equipo la tarea de estimar y desarrollar las historias correctamente.

Si queréis más información sobre los criterios de aceptación podéis descargar el manual Historias de usuario desde el Body of Knowledge de Scrum Manager o escuchar el episodio Definition of Done, disponible en Spotify e Ivoox.