«El formulario debe funcionar bien» deja demasiadas preguntas abiertas. ¿Qué datos son obligatorios? ¿Quién recibe la solicitud? ¿Qué ocurre si falta un dato o el envío falla? Los criterios de aceptación convierten una intención en condiciones observables para revisar una funcionalidad con el equipo.

Describe el resultado desde una persona y una tarea

Identifica quién actúa, qué intenta lograr y por qué. Después concreta lo necesario para considerar que esa necesidad está atendida. La guía de la Oficina Nacional de Estadística del Reino Unido describe los criterios como condiciones específicas que permiten comprobar si una necesidad quedó resuelta.

Evita confundir la solución con el resultado. «Agregar un botón azul» puede ser una decisión de interfaz; «la persona puede guardar un borrador y retomarlo» describe una capacidad que importa al proceso.

Incluye el camino normal y las excepciones

Una estructura útil es: dado un contexto, cuando ocurre una acción, entonces se observa un resultado. No es obligatorio adoptar una plantilla rígida; sí conviene que cada condición sea clara y comprobable por alguien que no la redactó.

Ejemplo hipotético para una solicitud: dado que faltan campos obligatorios, cuando la persona intenta enviarla, el sistema muestra qué debe completar y conserva la información ingresada. Otro criterio podría comprobar que, al enviarse correctamente, aparece una confirmación sin prometer tiempos que el equipo no haya acordado.

Acuerda pruebas, evidencias y límites

Decide quién revisará cada criterio, con qué datos y en qué entorno. Anota la versión evaluada y el resultado, sin usar información sensible real cuando no sea necesario. Si interviene un proveedor externo, verifica qué parte puedes probar y cuál depende de su disponibilidad.

Un criterio aceptado demuestra lo que se comprobó bajo ciertas condiciones. No garantiza que no existan otros defectos ni sustituye pruebas de seguridad, accesibilidad o rendimiento cuando el proyecto las necesita.

Lista antes de dar por terminada una historia

  • ¿Se entiende la tarea y quién la realiza?
  • ¿Cada condición describe un resultado verificable?
  • ¿Se incluyeron permisos, datos inválidos y fallos relevantes?
  • ¿Quedaron claros los límites y las dependencias externas?
  • ¿Hay una persona responsable de revisar y registrar el resultado?

Si una condición admite interpretaciones diferentes, plantea un ejemplo concreto y ajústala con el equipo antes de construir. Esa conversación suele ser más valiosa que una lista extensa que nadie puede comprobar.

Haz que cada criterio tenga una evidencia

Relaciona cada condición con una acción concreta: la persona autorizada ejecuta un paso, observa el resultado y registra si coincide con lo acordado. Una captura puede mostrar una interfaz, pero no necesariamente demuestra que el registro quedó guardado o que otro rol no puede verlo. Elige la evidencia según el riesgo y evita copiar datos personales a informes compartidos.

Cuando un criterio depende de un tercero que no está disponible, anótalo como pendiente y acuerda cómo se validará más adelante. No lo marques como cumplido solo porque el resto de la pantalla funciona. Del mismo modo, cambiar un criterio durante la revisión requiere dejar constancia del acuerdo para que ambas partes entiendan qué se aceptó.

Fuentes consultadas

Definamos el alcance de tu proyecto

Comparte una tarea que tu equipo necesita resolver y sus condiciones más importantes.

Conversemos sobre el alcance