Cómo escribir criterios de aceptación que de verdad zanjen la discusión
Una historia de usuario es solo el punto de partida de una conversación, y los criterios de aceptación son el lugar donde esa conversación queda fijada. Establecen las condiciones que un elemento del Product Backlog debe cumplir antes de que alguien acepte que está terminado. Sin ellos, «terminado» se desvía: el desarrollador cree que la funcionalidad funciona, el Product Owner esperaba otra cosa y el desacuerdo aflora en la Sprint Review, cuando es más caro corregirlo.
Con equipos distribuidos e híbridos ya convertidos en la norma tras un largo período de trabajo remoto, ya no puedes apoyarte en una charla rápida de pasillo para aclarar una ambigüedad. La historia y sus criterios deben sostener el significado por sí solos. Redactarlos bien es una de las inversiones en calidad más baratas que puede hacer un equipo.
Cómo son unos buenos criterios de aceptación
Los criterios de aceptación no son un documento de diseño ni guiones de prueba. Describen resultados observables desde el punto de vista del usuario, no la implementación. Tampoco son lo mismo que la Definition of Done, una confusión que conviene aclarar pronto: la Definition of Done es un estándar compartido que se aplica a todos los elementos del Product Backlog, mientras que los criterios de aceptación son propios de una sola historia. Si los mezclas, o cargas cada historia de texto repetido, o dejas que se relajen sin querer las exigencias de calidad. Un buen conjunto de criterios es:
Verificable — puedes decir con claridad si pasa o falla, sin interpretaciones
Centrado en el resultado — lo que el usuario ya puede hacer, no cómo lo hace el código
Independiente — cada criterio se sostiene por sí mismo
Sin detalle de solución — deja el «cómo» a las personas desarrolladoras
Reducido en número — de tres a siete puntos, no una especificación
Un formato legible y muy usado es Dado–Cuando–Entonces: dado un contexto, cuando ocurre una acción, entonces se produce un resultado concreto. No es obligatorio —una simple lista de comprobación también sirve—, pero te obliga a nombrar la condición previa, el disparador y el resultado esperado.
Una forma práctica de redactarlos
Parte del objetivo del usuario. Reformula lo que la persona intenta lograr antes de enumerar cualquier condición. Si no puedes nombrar el objetivo, la historia no está lista.
Describe primero el camino feliz. Escribe los criterios del caso normal y exitoso. Es la columna vertebral en la que todos coinciden.
Añade luego los casos límite que importan. Entradas vacías, el máximo permitido, una sesión expirada, un pago rechazado. Incluye solo los casos límite que cambian el comportamiento, no todos los teóricos.
Haz que cada criterio sea comprobable. Sustituye «rápido», «fácil de usar» o «seguro» por algo que puedas verificar: un número, un estado visible, un mensaje concreto.
Confírmalos con el equipo, no solo con el Product Owner. Las personas desarrolladoras y de pruebas detectarán casos faltantes y supuestos ocultos antes de empezar el trabajo.
Mantenlos separados de la Definition of Done. Los criterios son propios de esta historia; la Definition of Done se aplica a todos los elementos y cubre aspectos como pasar las pruebas y revisar el código.
Errores comunes que evitar
Tres trampas aparecen una y otra vez. La primera es colar el diseño: «añadir un desplegable» es una solución, mientras que «el usuario puede elegir entre las regiones aprobadas» es un resultado. La segunda son criterios tan vagos que no pueden fallar, como «funciona correctamente». La tercera es dejar que la lista crezca hasta convertirse en una miniespecificación de veinte puntos; eso es señal de que la historia debería dividirse. Hay además un fallo más silencioso: redactar los criterios una vez y no volver a revisarlos, aunque la conversación durante el Sprint cambie lo que el equipo ha aprendido. Trátalos como algo vivo hasta que el elemento esté terminado.
Cuando los criterios de aceptación son claros, la Sprint Review deja de ser una negociación para convertirse en una demostración, y la previsión del equipo se vuelve más estable porque todos estiman lo mismo. También facilitan mucho dividir una historia grande en porciones más pequeñas y con valor propio, porque los criterios muestran las costuras naturales. Dedicarles diez minutos antes de empezar suele ahorrar horas de retrabajo y la fricción que lo acompaña.
Si tus historias siguen provocando discusiones de «eso no era lo que quería» en la revisión, la asesoría en entrega de programas y proyectos de XNM puede ayudar a tus equipos a redactar criterios sólidos y a estrechar el camino del backlog al software funcional.