Criterios de aceptación

read time

3 min

Glosario de producto: criterios de aceptación

Los Criterios de Aceptación (CA’s) son un conjunto de escenarios o comportamientos en formato checklist o lista de comprobación añadidos a las historia de usuario (HU) para, por un lado definir qué espera el usuario, o negocio, de esa HU cuando esté acabada, y por otro lado para que las personas que desarrollan esa HU y la persona con la responsabilidad de Product Owner o Product Manager puedan validar que cumple con las expectativas.

Generalmente, están escritos por el Product Owner (a veces en colaboración con desarrollo) o por la persona con el rol de QA

Para formalizar los Criterios de Aceptación, a menudo se usa una estructura inspirada en el lenguaje Gherkin dedicado a la descripción de comportamientos de software (BDD o Behavior Driven Development) en lugar de la tradicional  descripción basada en pruebas (TDD o Test Driven Development).

Esta estructura usa la regla DADO-CUANDO-ENTONCES:

  • DADO (Given) un contexto inicial.  Definimos el estado del software antes de la ejecución de la HU, situación inicial.
  • CUANDO (When) se produce un evento. La acción que desencadena o detona un proceso.
  • ENTONCES (Then) se produce un resultado. El estado del software después de la ejecución, situación final.

Por ejemplo, para una HU relacionada con un formulario de inicio de sesión, un Criterio de Aceptación sería: «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña, CUANDO haga clic en el botón «Conectar» ENTONCES navega a la página de inicio del sitio».

Un Criterio de Aceptación no debe ofrecer una solución técnica, debe estar escrito desde el punto de vista del usuario y describir el comportamiento o escenario esperado por el producto al recibir un comportamiento natural de un usuario.

A la hora de escribir Criterios de Aceptación, una buena práctica sería escribir el escenario ideal o el happy path y después en los siguientes CA’s ir rompiendo ese escenario ideal.

En el ejemplo anterior habríamos descrito el escenario ideal, por tanto, para escribir los siguientes escenarios podríamos hacernos las siguientes preguntas (entre otras):

  • Qué ocurre si el usuario o la contraseña son incorrectas
  • Qué ocurre si uno de los campos o los dos están vacíos
  • Qué ocurre si pulsa varias veces en el botón de «Conectar»
  • Existe algún número máximo de reintentos
  • Qué ocurre si nuestro sistema está caído y da un time out
  • Etc.

A veces, se pueden dar escenarios complejos donde concatenamos varias condiciones, eventos y resultados.

Para el ejemplo anterior:  «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña y cuyo navegador sea chrome con una pestaña de incógnito, CUANDO haga clic en el botón «Conectar» y no ha aceptado la política de privacidad y no ha aceptado las cookies, ENTONCES navega a la página de inicio del sitio y aparece un popup solicitando que acepte las políticas de privacidad y aparece el banner de cookies».

Este tipo de Criterios de Aceptación tan complejos suelen trabajarse de forma independiente dividiéndolo en 3 CA’s diferentes. Por ejemplo:

  1.  «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña, CUANDO haga clic en el botón «Conectar» ENTONCES navega a la página de inicio del sitio».
  2. «DADO un usuario cuyo navegador sea chrome con una pestaña de incógnito, CUANDO inicie sesión sin aceptar la política de privacidad, ENTONCES aparece un popup solicitando que acepte las políticas de privacidad en la página de inicio».
  3.  «DADO un usuario cuyo navegador sea chrome con una pestaña de incógnito, CUANDO inicie sesión aceptar las cookies, ENTONCES aparece el banner de cookies en la página de inicio».

Para el desarrollo de buenos Criterios de Aceptación solemos recomendar el uso de talleres de alineación como Tres Amigos, donde involucramos a una persona que represente a desarrollo o IT, a una persona que representa a Diseño y a una persona que representa a negocio como es el Product Owner.

No es necesario que haya tres personas, pero sí deben estar representadas las 3 áreas de responsabilidad o competencias. 

Se pondrán de acuerdo sobre los escenarios de los criterios de aceptación y luego compartirán la redacción usando Gherkin.

Para saber más: descarga el libro Agile Product Management
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

Publicado el 10 ene 2022

Actualizado el 26 mar 2024

clipboardCopiar el enlace
Escrito por
Víctor Corrales
Víctor Corrales Product Coach y People Manager en Thiga España. Experto resolviendo problemas complejos sirviendo a las necesidades, deseos y problemáticas concretas de otras personas. Con experiencia en las grandes telcos, e-commerce y retail, sirve su experiencia a equipos y líderes adaptando las mejores prácticas de producto a sus contextos, facilitando la comunicación, aplicando dinámicas colaborativas, gestionando conflictos y gestionando expectativas.

Próximos eventos

LPCx BCN: Product Management & Product Design

calendar

20 marzo 2024

Apúntate

La Product Conf Madrid 2024

calendar

17 mayo 2024

Apúntate

Filles_ordinateur

¿Quieres compartir con el mundo tu pasión por los temas de producto?

Cada mes, más de 20.000 entusiastas del producto digital visitan nuestro media. Comentarios, opiniones controvertidas... ¡compártenos eso que tienes en mente!

 

Contactar con la redacción