PREPARAR LA TAREA

Cómo redactar criterios de aceptación

Los buenos criterios describen un resultado comprobable. Las decisiones pendientes deben seguir visibles.

3 min de lectura

Para qué sirven los criterios de aceptación

Los criterios de aceptación establecen las condiciones para aceptar un cambio. Permiten que quien solicita, desarrolla y prueba comparta la misma idea del resultado. «Utilizar un hook de React» puede ser una restricción técnica, pero no describe un comportamiento observable.

Un criterio útil indica contexto, acción y resultado verificable. «La exportación debe ser rápida» no basta: primero hay que acordar un objetivo, un volumen de datos y cómo se medirá. El ticket explica el problema y el alcance; los criterios definen la aceptación. La Definition of Done del equipo, que puede incluir revisión y pruebas, no sustituye los criterios propios de la tarea.

Requisito confirmado o supuesto

«Exportar clientes» no define formato, permisos, columnas ni qué ocurre si no hay resultados. Esas son decisiones pendientes. Una recomendación puede proponer una opción, pero no se convierte en requisito hasta que alguien la aprueba. Separa en el ticket lo confirmado, lo propuesto y lo pendiente.

Tres ejemplos

Función: exportar un informe. Débil: «El usuario puede exportar todos los datos fácilmente». Tras acordar el comportamiento: «Una persona con permiso Informes descarga un CSV en UTF-8 con todas las filas que cumplen los filtros actuales, incluidas las que no aparecen en la página visible». Confirma las columnas y el caso sin filas antes de añadir más criterios.

Error: inicio de sesión. Débil: «El inicio de sesión vuelve a funcionar». Mejor: «Con una cuenta válida y autenticación de dos factores, después de restablecer la contraseña e introducir el código correcto se abre la sesión y no aparece el error comunicado». Solo sirve si el fallo se reproduce en esas condiciones. Incluye pasos y entorno.

Tarea técnica: actualización de API. Sustituye «pasar a v2 sin romper nada» por una versión y un entorno concretos. Comprueba que las solicitudes de facturas afectadas conservan los campos y códigos acordados y que las pruebas de integración pasan contra v2.

Cuándo usar Dado / Cuando / Entonces

El formato ayuda cuando el orden y las condiciones cambian el resultado, como en un flujo de acceso. Para cambiar el texto de un botón suele añadir formalismo. Una actualización de PHP necesita versión objetivo, integraciones afectadas y comprobaciones, no una historia artificial. Escribe solo los criterios necesarios para decidir si el trabajo está terminado.

Antes de redactarlos, revisa el objetivo y las decisiones abiertas con la herramienta de preparación de tareas. Su resultado sirve para conversar, no para aprobar automáticamente. Consulta la lista de preparación y la comparación con Definition of Ready.

← Volver a recursos