Criterios de aceptación: cómo escribirlos (con ejemplos)

Los criterios de aceptación son las condiciones que una historia de usuario debe satisfacer antes de que su equipo la considere lista para publicar. Defínalos bien y reducirá el retrabajo, las discusiones y los errores sorpresa durante la revisión.

¿Qué son los criterios de aceptación?

Los criterios de aceptación son un conjunto de condiciones específicas y verificables asociadas a una historia de usuario individual. Definen qué debe hacer la funcionalidad (y qué no debe hacer) desde la perspectiva del usuario. Cuando todas las condiciones se cumplen, la historia es aceptada. Cuando al menos una falla, el trabajo continúa.

Piense en ellos como el contrato entre la persona que solicitó la funcionalidad y el equipo que la construye. Sin suposiciones. Sin "creí que querías decir otra cosa." Solo una lista clara de condiciones de aprobación o rechazo, escritas antes de que comience el desarrollo.

Los criterios de aceptación pertenecen al nivel de la historia. Responden a la pregunta: "¿Cómo sabremos que esta historia está terminada?" Esa es una pregunta diferente de "¿Cómo sabremos que el Sprint está terminado?", que es lo que responde la Definition of Done.

Datos clave

• El formato Given-When-Then para los criterios de aceptación fue introducido por Dan North como parte del desarrollo guiado por comportamiento (BDD) alrededor de 2006, brindando a los equipos una manera estructurada y verificable de expresar el comportamiento esperado. (Fuente: Dan North, "Introducing BDD," dannorth.net, 2006.)
• La Agile Alliance señala que los criterios de aceptación ambiguos o inexistentes son una de las causas más comunes de retrabajo en proyectos Agile. (Fuente: Agile Alliance Glossary, agilealliance.org.)
• Los equipos que escriben criterios de aceptación antes de codificar reportan transferencias más ágiles del desarrollo a QA, porque los testers ya saben qué verificar.

Formatos para escribir criterios de aceptación

Hay dos formatos que los equipos utilizan con mayor frecuencia. Ninguno es universalmente superior. Elija el que mejor se adapte a la forma de trabajar de su equipo.

Given-When-Then (basado en escenarios)

También llamado formato Gherkin, proviene del desarrollo guiado por comportamiento (BDD). Estructura cada condición como un escenario con tres partes:

• Given (Dado que) -- el estado o contexto inicial
• When (Cuando) -- la acción que realiza el usuario
• Then (Entonces) -- el resultado esperado

Ejemplo: inicio de sesión del usuario:

Given a registered user is on the login page
When they enter a valid email and correct password and click "Sign In"
Then they are redirected to their dashboard and see a welcome message

Given a registered user is on the login page
When they enter a valid email and an incorrect password
Then they see an error message: "Email or password is incorrect" and remain on the login page

Este formato funciona bien cuando el comportamiento es secuencial y se pueden escribir múltiples escenarios de fallo junto con los caminos felices. Los ingenieros de QA pueden convertir cada escenario directamente en un caso de prueba.

Basado en reglas (lista de verificación)

Algunos equipos prefieren una lista con viñetas de reglas. Este formato es ideal para historias donde las condiciones son independientes en lugar de secuenciales.

Ejemplo: búsqueda de productos:

- Los resultados de búsqueda aparecen en menos de 2 segundos para cualquier consulta
- Los resultados se ordenan por relevancia de forma predeterminada
- Los usuarios pueden filtrar por categoría, rango de precio y calificación
- Si no se encuentran resultados, la página muestra: "No hay resultados para [consulta]. Pruebe con otras palabras."
- La barra de búsqueda conserva la consulta del usuario después de que carguen los resultados

Los criterios de aceptación basados en reglas son más rápidos de escribir y más fáciles de revisar. Funcionan mejor para restricciones de interfaz, requisitos de rendimiento y casos extremos que no encajan bien en una secuencia de acciones del usuario.

Criterios de aceptación vs Definition of Done

Estos dos conceptos se confunden con frecuencia. Resuelven problemas distintos.

Una historia puede pasar todos sus criterios de aceptación y aún así reprobar la Definition of Done, por ejemplo, si le faltan pruebas unitarias o no fue revisada por un par. Ambas listas deben aprobarse para que el trabajo esté verdaderamente completo.

Consulte el análisis completo en el artículo sobre la Definition of Done.

Características de los buenos criterios de aceptación

No toda lista de condiciones califica como buenos criterios de aceptación. Esto es lo que separa los criterios útiles de los vagos:

Verificables. Cada condición debe tener un resultado claro de aprobación o rechazo. "La interfaz se ve bien" no es verificable. "El botón cumple con una relación de contraste de 4.5:1" sí lo es.

Escritos desde la perspectiva del usuario. Los criterios de aceptación describen lo que el usuario experimenta, no cómo está estructurado el código. Evite los detalles de implementación como "la API devuelve un estado 200." Prefiera "el usuario ve su perfil actualizado de inmediato."

Específicos. Los números, los estados y las etiquetas importan. "Respuesta rápida" se convierte en "respuesta en menos de 1,5 segundos." "Un mensaje de error" se convierte en "el texto exacto: 'La contraseña debe tener al menos 8 caracteres'."

Acordados antes de que comience el desarrollo. Los criterios escritos después de que se construye la funcionalidad tienden a justificar lo que se hizo en lugar de describir lo que se necesitaba. Escríbalos durante el backlog refinement.

No demasiados. Un rango de tres a ocho condiciones es saludable. Una historia con quince criterios de aceptación probablemente contiene dos o tres historias dentro de una sola.

Cómo escribir criterios de aceptación

Paso 1: Comience con la historia de usuario

No puede escribir criterios de aceptación sin una historia de usuario clara. Confirme que tiene una en este formato:

Como [persona], quiero [objetivo], para que [motivo].

Si la historia es vaga, defínala mejor antes de escribir las condiciones.

Paso 2: Pregúntese "¿qué debe ser verdadero para que esto funcione?"

Enumere los comportamientos y resultados que la funcionalidad debe producir. Cubra primero el camino feliz, luego los casos extremos y los estados de fallo.

Paso 3: Elija un formato

Elija Given-When-Then si el comportamiento es secuencial y QA liderará la creación de pruebas. Elija el formato basado en reglas si las condiciones son independientes o si el tiempo es limitado.

Paso 4: Escriba en lenguaje verificable

Reemplace las palabras vagas. "Rápidamente" se convierte en un número. "Con el formato correcto" se convierte en el formato exacto. "Debe funcionar en móvil" se convierte en "el diseño es responsivo a 375px de ancho."

Paso 5: Revíselos con el equipo antes de que comience el desarrollo

Comparta el borrador con los desarrolladores, QA y las partes interesadas. Los desarrolladores detectarán condiciones técnicamente imposibles. QA identificará casos extremos faltantes. Las partes interesadas corregirán errores de lógica de negocio. Haga esto durante el backlog refinement o la sprint planning para que todos estén alineados antes de escribir una sola línea de código.

Paso 6: Adjúntelos a la historia

Agregue los criterios finalizados a la historia en su product backlog. Permanecen adjuntos durante todo el desarrollo y son la lista de verificación que su equipo utiliza durante la sprint review.

Ejemplos de criterios de aceptación

A continuación se presentan tres ejemplos detallados para distintos tipos de historia.

Ejemplo 1: Inicio de sesión del usuario

Historia: Como usuario registrado, quiero iniciar sesión con mi correo electrónico y contraseña, para poder acceder a mi cuenta.

Given the user is on the sign-in page
When they enter a registered email and correct password and click "Sign In"
Then they are redirected to their dashboard within 2 seconds

Given the user enters an incorrect password three times
When they attempt a fourth login
Then the account is locked for 30 minutes and the user sees:
"Too many failed attempts. Try again in 30 minutes."

Given the user is signed in
When they click "Sign Out"
Then their session ends and they are redirected to the homepage

Ejemplo 2: Total de la compra

Historia: Como comprador, quiero ver el total de mi pedido antes de pagar, para saber exactamente cuánto debo abonar.

Ejemplo 3: Búsqueda sin resultados

Historia: Como usuario, quiero saber cuándo mi búsqueda no arroja resultados, para poder probar con otras palabras.

- Cuando una búsqueda devuelve cero resultados, la página muestra: "No hay resultados para '[consulta]'. Pruebe con otras palabras."
- La barra de búsqueda conserva la consulta original del usuario
- Sugerencias de categorías relacionadas aparecen debajo del mensaje si están disponibles
- El título de la página se actualiza para reflejar el estado de búsqueda vacía

Errores comunes que debe evitar

Escribirlos después de los hechos. Los criterios de aceptación escritos tras el desarrollo describen lo que se construyó, no lo que se necesitaba. Escríbalos primero.

Ser vago sobre los estados de error. Los criterios que solo cubren el camino feliz dejan a los desarrolladores adivinando cómo manejar los fallos. Incluya siempre al menos un escenario de fallo.

Mezclar implementación técnica. "El servicio llama a la API de pago con una solicitud POST" no es un criterio de aceptación. "El usuario ve una confirmación de pago en menos de 3 segundos" sí lo es.

Hacerlos demasiado extensos. Si sus criterios de aceptación cubren múltiples funcionalidades distintas, divida la historia. Una buena historia con buenos criterios cabe en una tarjeta índice.

Omitir la revisión del equipo. Los criterios escritos de forma individual (generalmente por el Product Owner) pierden restricciones técnicas de los desarrolladores y casos extremos de QA. Revíselos juntos antes de que comience el Sprint. Use las agile ceremonies de refinement para hacerlo de forma consistente.

Preguntas frecuentes

¿Qué son los criterios de aceptación?

Los criterios de aceptación son las condiciones específicas y verificables que una historia de usuario debe satisfacer antes de que el equipo la acepte como completa. Definen qué debe hacer la funcionalidad desde la perspectiva del usuario, y se escriben antes de que comience el desarrollo.

¿Quién escribe los criterios de aceptación?

El Product Owner generalmente redacta los criterios de aceptación, pero todo el equipo (desarrolladores, QA y a veces las partes interesadas) los revisa y refina antes de que comience el desarrollo. Escribirlos de forma aislada genera casos extremos omitidos y retrabajo.

¿Cuál es la diferencia entre los criterios de aceptación y la Definition of Done?

Los criterios de aceptación son por historia: describen qué debe hacer una funcionalidad específica. La Definition of Done es global: es una lista de verificación que se aplica a cada historia del Sprint (revisión por pares, cobertura de pruebas, documentación, etc.). Una historia debe pasar ambas antes de salir a producción.

¿Qué es Given-When-Then?

Given-When-Then es un formato estructurado para escribir criterios de aceptación como escenarios verificables. "Given" establece el contexto, "When" describe la acción del usuario y "Then" indica el resultado esperado. Fue introducido por Dan North como parte del desarrollo guiado por comportamiento (BDD) alrededor de 2006 y es ampliamente utilizado en equipos Agile hoy en día.

¿Cuántos criterios de aceptación debe tener una historia de usuario?

Apunte a entre tres y ocho. Menos de tres suele indicar que la historia está poco especificada. Más de ocho generalmente significa que la historia es demasiado grande y debería dividirse en historias más pequeñas.

---

Los buenos criterios de aceptación no garantizan un producto excelente, pero previenen una categoría específica de fallos: construir algo que nadie tenía la intención de construir. Escríbalos temprano, revíselos en equipo, y verá que sus sprint reviews dejan de ser debates sobre qué significa "listo" para convertirse en demostraciones directas de software funcionando.