Publicaciones

Cómo escribir criterios de aceptación que realmente previenen el retrabajo

Equipo ágil colaborando alrededor de una mesa con notas adhesivas y una laptop, discutiendo requisitos para una historia de usuario durante una sesión de refinamiento de backlog Los problemas relacionados con requisitos causan casi la mitad de todos los defectos de software. La mayoría de ellos se remontan al mismo problema raíz: el equipo construyó lo que pensó que se pedía, no lo que realmente se necesitaba. Los criterios de aceptación son la solución. Convierten una historia de usuario vaga en un contrato verificable entre el product owner y el equipo de desarrollo. Cuando están bien escritos, eliminan las conversaciones de "pero pensé que debería..." que descarrilan las revisiones de sprint. Esta guía cubre los dos formatos principales, ejemplos reales que puedes adaptar y los errores que tropiezan hasta a equipos experimentados.

Qué son (y qué no son) los criterios de aceptación

Los criterios de aceptación son las condiciones que una historia de usuario debe satisfacer antes de considerarse completa. Responden una pregunta: "¿Cómo sabremos que esto funciona?" No son lo mismo que una definición de terminado. La DoD es un estándar de calidad universal que se aplica a todo el trabajo (código revisado, pruebas escritas, desplegado en staging). Los criterios de aceptación son específicos de una sola historia.

	Criterios de aceptación	Definición de Terminado
Alcance	Una historia de usuario	Todos los elementos de trabajo
Enfoque	Qué hace la funcionalidad para los usuarios	Qué tan bien está construida
Quién lo escribe	Product Owner + equipo	Todo el Scrum Team
Ejemplo	"Usuario puede filtrar por rango de fechas"	"Código revisado por al menos 1 dev"

Ambos deben satisfacerse antes de que una historia esté terminada. Si todavía estás construyendo tu DoD, nuestro Generador de Definición de Terminado puede ayudarte a empezar.

Los dos formatos principales

Formato de lista de verificación (basado en reglas)

Una lista simple de condiciones de pasa/falla. Mejor para funcionalidades directas donde el comportamiento esperado es claro.

Funcionalidad de restablecimiento de contraseña:
- El enlace "Olvidé mi contraseña" aparece en la página de inicio de sesión
- Al hacer clic solicita una dirección de correo electrónico
- Un correo válido recibe un enlace de restablecimiento en 60 segundos
- El enlace de restablecimiento expira después de 24 horas
- La nueva contraseña debe cumplir los requisitos de contraseña existentes
- Después del restablecimiento, el usuario es redirigido al inicio de sesión con un mensaje de éxito
- Un correo inválido muestra: "Si este correo existe, se ha enviado un enlace de restablecimiento"

Cuándo usarlo: Funcionalidades simples, requisitos de UI, reglas de negocio, lógica de validación. La mayoría de tus historias usarán este formato.

Formato Given/When/Then (Gherkin)

Un formato de escenario estructurado del Desarrollo Guiado por Comportamiento. Cada escenario describe una precondición, una acción y un resultado esperado.

Escenario: Aplicar un código de descuento válido
Given el usuario tiene artículos en su carrito con un total de $100
And existe un código de descuento válido del 20% "SAVE20"
When el usuario ingresa "SAVE20" en el campo de descuento
And hace clic en "Aplicar"
Then el total del carrito se actualiza a $80
And aparece un mensaje "Descuento aplicado"

Escenario: Aplicar un código de descuento expirado
Given el código de descuento "OLD10" expiró ayer
When el usuario ingresa "OLD10" y hace clic en "Aplicar"
Then el total del carrito permanece sin cambios
And aparece un mensaje de error "Este código ha expirado"

Cuándo usarlo: Flujos de trabajo complejos con múltiples rutas, o funcionalidades que planeas automatizar con herramientas BDD como Cucumber o SpecFlow. Dos documentos lado a lado mostrando el formato de lista de verificación y el formato Given/When/Then para criterios de aceptación, con anotaciones coloridas destacando las diferencias

¿Qué formato deberías elegir?

La mayoría de los equipos llegan a un enfoque híbrido: lista de verificación para historias simples, Given/When/Then para cualquier cosa con ramificaciones complejas o múltiples rutas de usuario. No le des muchas vueltas. Elige el formato que comunique los requisitos más claramente para esa historia específica.

Cinco reglas para escribir buenos criterios de aceptación

1. Define el qué, no el cómo

Mal: "Usar un componente modal con una animación de fade-in de 400ms" Bien: "Aparece un diálogo de confirmación antes de que se elimine el elemento" Los criterios describen resultados. La implementación es el trabajo del desarrollador.

2. Haz que cada criterio sea verificable

Si no puedes responder "sí" o "no" a si un criterio se cumple, es demasiado vago. Mal: "La página debe cargar rápido" Bien: "Los resultados de búsqueda cargan en 2 segundos para hasta 500 resultados"

3. Cubre el camino triste

Por cada camino feliz, escribe al menos un escenario de error. ¿Qué sucede con entrada inválida? ¿Una conexión caída? ¿Permisos faltantes?

4. Mantén los criterios independientes

Cada criterio debe ser verificable por sí solo. Si el criterio #4 solo tiene sentido después de leer los criterios #1 al #3, has escrito una especificación, no criterios de aceptación.

5. Escríbelos antes de la planificación de sprint

Los criterios de aceptación escritos durante el desarrollo son descripciones, no requisitos. Escríbelos durante el refinamiento de backlog para que el equipo pueda estimar con precisión durante el planning poker.

Ejemplos del mundo real

Filtro de búsqueda de comercio electrónico

Historia de usuario: "Como comprador, quiero filtrar productos por múltiples categorías para poder reducir los resultados a lo que estoy buscando."

• Los filtros muestran todas las categorías de productos disponibles
• Los usuarios pueden seleccionar múltiples categorías a la vez
• Los resultados se actualizan en tiempo real sin refrescar la página
• Los filtros aplicados se muestran como insignias removibles
• El botón "Limpiar todo" elimina todos los filtros activos
• El conteo de resultados se actualiza para reflejar los filtros activos (ej., "Mostrando 47 resultados")
• Sin resultados coincidentes muestra: "Ningún producto coincide con tus filtros. Intenta ampliar tu selección."
• El estado del filtro persiste al navegar de regreso desde una página de detalle de producto

Flujo de invitación de equipo

Historia de usuario: "Como líder de equipo, quiero invitar miembros por correo electrónico para que podamos comenzar a colaborar."

Escenario: Invitación exitosa
Given estoy en la página de configuración del equipo
When ingreso "alex@company.com" en el campo de invitación
And hago clic en "Enviar Invitación"
Then se envía un correo de invitación en 60 segundos
And el correo aparece en mi lista de "Invitaciones Pendientes"
And un mensaje de éxito confirma que la invitación fue enviada

Escenario: Invitación duplicada
Given ya invité a "alex@company.com"
When ingreso el mismo correo y hago clic en "Enviar Invitación"
Then aparece una advertencia: "Ya se envió una invitación a este correo"
And puedo elegir reenviar o cancelar

Escenario: Formato de correo inválido
Given estoy en la página de configuración del equipo
When ingreso "no-es-un-correo" y hago clic en "Enviar Invitación"
Then aparece un error en línea: "Ingresa una dirección de correo válida"
And no se envía ninguna invitación

Preferencias de notificaciones

Historia de usuario: "Como usuario, quiero controlar qué notificaciones recibo para no estar abrumado por alertas."

• La página de configuración muestra un interruptor para cada categoría de notificación
• Los cambios se guardan automáticamente (sin botón "Guardar" separado)
• Desactivar una categoría detiene todas las notificaciones de ese tipo en 5 minutos
• Al menos un canal de notificación debe permanecer activo (prevenir la exclusión accidental de todo)
• "Restablecer a valores predeterminados" restaura la configuración original de notificaciones
• Los cambios se aplican en todos los dispositivos

Un desarrollador revisando una tarjeta de historia de usuario con criterios de aceptación claramente escritos, marcando elementos uno por uno

Errores comunes

Ser demasiado vago. "El sistema debe ser fácil de usar" no es verificable. Reemplaza el lenguaje subjetivo con condiciones medibles. Prescribir implementación. "Usar Redux para gestión de estado" pertenece a un spike técnico, no a criterios de aceptación. Describe lo que el usuario experimenta, no cómo funciona el código. Solo escribir el camino feliz. Si tus criterios solo cubren el escenario de sol, tu equipo descubrirá casos extremos a mitad del sprint y o tomará atajos o reventará la estimación. Escribir criterios demasiado tarde. Los criterios escritos durante el desarrollo son justificaciones retroactivas, no requisitos. Defínelos durante el refinamiento, afínalos durante la planificación de sprint. Hacer criterios demasiado granulares. Si tus criterios se leen como un script de prueba con 30 pasos, te has pasado. Apunta a 5-10 criterios por historia. Si necesitas más, la historia probablemente es demasiado grande y debería dividirse en historias más pequeñas.

Una verificación rápida

Antes de comprometer una historia a un sprint, revisa esto: Si alguno de esos falla, la historia necesita otra ronda de refinamiento de backlog antes de estar lista para el sprint.

Escribir criterios de aceptación más rápido

El enfoque "Three Amigos" funciona: reúne al product owner, un desarrollador y un tester en la misma sala para cada historia. El PO explica la intención, el desarrollador detecta casos extremos técnicos, y el tester hace agujeros con preguntas de "¿qué pasaría si...?". Si estás escribiendo historias de usuario y necesitas un punto de partida, nuestro Generador de Criterios de Aceptación puede redactar criterios iniciales a partir de una descripción de historia. Te lleva al primer 80% rápidamente para que tu equipo pueda pasar el tiempo de refinamiento en los casos extremos complicados en lugar de mirar una página en blanco.