Cuando un equipo celebra haber terminado una funcionalidad y el cliente responde "esto no es lo que pedí", el problema rara vez está en el código. La raíz suele ser que nadie definió con precisión cuándo esa historia estaba realmente lista. Entender cómo se escriben y aplican los criterios de aceptación es la diferencia entre entregar software que cumple expectativas y acumular retrabajo costoso.
¿Qué son los criterios de aceptación y por qué importan tanto?
Los criterios de aceptación son las condiciones específicas que una funcionalidad debe cumplir para que alguien autorizado —product owner, cliente— la acepte como completa [0:24]. La analogía es directa: en un restaurante, antes de que un plato salga de la cocina, alguien revisa ingredientes, temperatura y presentación. Si falta algo, el plato no sale. Exactamente eso hacen los criterios de aceptación con el software.
Su utilidad va más allá de la validación final. Sirven para:
- Estimar trabajo con mayor precisión.
- Planificar pruebas desde el inicio.
- Alinear a desarrolladores, testers y producto en la misma meta antes de escribir una línea de código.
¿Cuál es la diferencia entre criterios de aceptación y definición de terminado?
Esta confusión es frecuente y peligrosa [0:59]. La definición de terminado (definition of done) funciona como las normas sanitarias del restaurante: aplican a cada plato sin excepción. Incluye revisión de código, documentación y pruebas unitarias pasando. Los criterios de aceptación, en cambio, son específicos de una historia. Responden si esa funcionalidad en particular hace lo que prometió. Confundirlos lleva a omitir condiciones de negocio pensando que la definición de terminado ya las cubre.
¿Cómo escribir criterios sin ambigüedad con dado-cuando-entonces?
El formato dado-cuando-entonces proviene de Behavior-Driven Development (BDD) y es la herramienta más efectiva para eliminar la vaguedad [1:27]. Cada parte cumple un rol claro:
- Dado: describe la situación inicial, los actores en posición.
- Cuando: describe la acción que ocurre.
- Entonces: describe el resultado esperado.
Un ejemplo concreto: dado que el usuario está en la página de login, cuando ingresa usuario y contraseña válidos, entonces es redirigido al dashboard de su cuenta. La potencia de este formato es que el desarrollador, el tester y el cliente leen exactamente lo mismo y acuerdan el mismo resultado. Una sola fuente de verdad.
La regla fundamental es que cada escenario necesita una entrada concreta y un resultado concreto. Si falta cualquiera, no sirve como prueba.
¿Por qué palabras como "rápido" o "fácil" destruyen tus criterios?
Este es el error más dañino al redactar criterios de aceptación [2:05]. Palabras como "rápido", "fácil" o "seguro" son imposibles de verificar. Es como un letrero que dice "conduzca con cuidado" en vez de "sesenta kilómetros por hora".
La solución es reemplazar cada término vago con una métrica verificable:
- En lugar de "el sistema es rápido": "la página carga en menos de dos segundos para el 95% de los usuarios en horas pico".
- En lugar de "el registro es fácil": "un usuario nuevo completa el registro en menos de tres minutos sin asistencia".
Cada versión refinada responde una pregunta clave: ¿qué hacemos diferente si esto no se cumple?
¿Cómo se aplican los criterios de aceptación en un caso real de compra en línea?
Consideremos la historia: "como cliente, quiero completar mi compra en línea para recibir mis productos en casa" [2:52]. Se necesitan criterios para pago, envío y confirmación:
- Pago: dado que el usuario está en checkout con productos en el carrito y datos de tarjeta válidos, cuando hace clic en "Pagar Ahora", entonces el pago se autoriza y la orden avanza.
- Envío: dado que el pago fue autorizado y la dirección es válida, cuando el sistema procesa la orden, entonces se asigna método de envío y se muestra fecha estimada.
- Confirmación: dado que pago y envío están listos, cuando la orden se procesa completamente, entonces se muestra la página de confirmación y se envía correo en máximo dos minutos.
Ese "máximo dos minutos" —no "rápidamente"— es algo que un tester puede medir con cronómetro.
¿Cómo saber si un criterio está bien escrito?
La prueba definitiva es simple: ¿puedo verificarlo con un sí o un no? [3:26]. Piensa en un interruptor de luz: encendido o apagado. Si tu criterio funciona como un regulador de intensidad donde alguien puede argumentar "está más o menos hecho", necesitas reescribirlo.
Cuando un criterio falla durante las pruebas, se convierte directamente en un reporte de defecto. El "dado" y el "cuando" son los pasos para reproducir el problema. El "entonces" es el resultado esperado. Los campos del reporte ya están prácticamente llenos.
Piensa en tu proyecto actual: ¿hay alguna historia con criterios vagos que podrías reescribir hoy usando dado-cuando-entonces? Comparte tu ejemplo y cómo lo mejorarías.
