Definir con precisión cuándo una funcionalidad está lista es lo que separa a los equipos que entregan valor de aquellos que acumulan retrabajo. Cuando un equipo celebra haber terminado una historia de usuario y el cliente responde "esto no es lo que pedí", el problema rara vez está en el código: nadie estableció condiciones claras de aceptación antes de empezar a construir [0:07]. Aquí se explica cómo escribir esos acuerdos de forma que todos —desarrolladores, testers y product owner— compartan la misma meta.
¿Qué son los criterios de aceptación y por qué importan?
Los criterios de aceptación son las condiciones específicas que una funcionalidad debe cumplir para que alguien autorizado —el product owner o el cliente— la acepte como completa [0:26]. Funcionan como el control de calidad en una cocina de restaurante: antes de que el plato salga, alguien verifica ingredientes, temperatura y presentación. Si algo falta, el plato no sale [0:37].
En software cumplen tres funciones clave:
- Estimar trabajo con mayor precisión.
- Planificar pruebas antes de escribir código.
- Garantizar que desarrolladores, testers y producto compartan la misma meta desde el inicio [1:00].
¿Cuál es la diferencia con la definición de terminado?
Una confusión frecuente es mezclar criterios de aceptación con la definición de terminado (definition of done) [1:13]. La definición de terminado equivale a las normas sanitarias del restaurante: revisión de código, documentación y pruebas unitarias pasando. Aplica a cada historia sin excepción. Los criterios de aceptación, en cambio, son específicos de una historia y responden: ¿esta funcionalidad en particular hace lo que prometió? [1:36]. Confundirlos lleva a omitir condiciones de negocio pensando que la definición de terminado ya las cubre.
¿Cómo escribir criterios sin ambigüedad usando dado-cuando-entonces?
El formato dado-cuando-entonces proviene de Behavior-Driven Development (BDD) y cada parte cumple un rol preciso [0:51]:
- 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 [2:12]. El desarrollador, el tester y el cliente leen exactamente lo mismo y acuerdan el mismo resultado. Una sola fuente de verdad.
La regla que no se puede romper: cada escenario necesita una entrada concreta y un resultado concreto. Si falta cualquiera, no sirve como prueba [2:33].
¿Por qué la vaguedad es el error más dañino?
Palabras como "rápido", "fácil" o "seguro" destruyen la verificabilidad de un criterio [2:40]. Decir "el sistema es rápido" es como un letrero que dice "conduzca con cuidado" en vez de "sesenta kilómetros por hora". Nadie puede verificar eso.
La solución es reemplazar adjetivos vagos por métricas concretas [2:58]:
- 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: ¿qué hacemos diferente si esto no se cumple?
¿Cómo se aplica en un caso real de compra en línea?
Para la historia "como cliente, quiero completar mi compra en línea para recibir mis productos en casa" se necesitan criterios para pago, envío y confirmación [3:23]:
- 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 [4:10].
Ese "máximo dos minutos" —y no "rápidamente"— permite que un tester lo mida con cronómetro.
¿Cómo validar que un criterio está bien escrito?
La prueba definitiva para cada criterio: ¿puedo verificarlo con un sí o un no? [4:20]. Si funciona como un interruptor de luz —encendido o apagado— está bien. Si alguien puede argumentar "está más o menos hecho", hay que reescribirlo.
Cuando un criterio falla durante las pruebas, se convierte directamente en reporte de defecto: el "dado" y el "cuando" son los pasos para reproducir, y el "entonces" es el resultado esperado [4:41]. Ya tienes todo lo necesario para llenar esos campos.
¿Hay alguna historia en tu proyecto actual con criterios vagos que podrías reescribir hoy con dado-cuando-entonces?
