Los criterios de aceptación están escritos por el Product Owner (a veces en colaboración con el equipo de desarrollo o por el QA) y acompañan cada historia de usuario: representan un conjunto de condiciones que se deben cumplir para considerar la historia de usuario completa y terminada.
Para formalizar los criterios de aceptación, los Product Owner a menudo usan una estructura inspirada en el lenguaje Gherkin dedicado a la descripción de comportamientos de software. Esta estructura se llama DADO-CUANDO-ENTONCES:
- DADO (Given): el estado del software antes de la ejecución de la historia del usuario, situación inicial.
- CUANDO (When): un evento que desencadena un proceso.
- ENTONCES (Then): estado del software después de la ejecución, situación final.
Por ejemplo, para una historia de usuario relacionada con un formulario de inicio de sesión: «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. Los criterios de aceptación se pueden considerar casos de prueba o descripciones del comportamiento esperado por el producto al recibir un comportamiento natural de un usuario.
Para escribir los criterios de aceptación, puedes comenzar verificando si cumplen con la definición SMART:
- Específico (Specific): comprensible, fácil de reproducir.
- Medible (Measurable): cuantificable y observable.
- Alcanzable (Achievable): posible de lograr (sin excesiva complejidad).
- Relevante (Relevant): apropiado para la historia del usuario en cuestión.
- Tiempo límite (Time-Bound): con un tiempo de aplicación limitado en el tiempo.
Para saber más: descarga el libro Agile Product Management
Copiar el enlace
