Criterios de aceptación: Difference between revisions

Revision as of 10:30, 18 December 2023

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

Véase también

@@ Line 8: / Line 8: @@
 ==Elementos==
-*el número de escenario;
+*el '''número de escenario''';
-*el título, donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”;
+*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 '''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»;
+*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».
+*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.