Cómo escribir criterios de aceptación en Jira, con ejemplos prácticos

«Los clientes pueden cambiar sus preferencias de notificaciones» parece una incidencia de Jira clara hasta que alguien empieza a implementarla. ¿Se guarda el cambio inmediatamente? ¿Qué ocurre si falla el guardado? ¿Seguirá ahí la preferencia mañana? ¿Qué correos se ven afectados?

Los criterios de aceptación convierten esas preguntas abiertas en resultados acordados y observables. Ayudan a que quienes solicitan, construyen y revisan un cambio trabajen con las mismas expectativas.

En esta guía desarrollaremos criterios para una funcionalidad ficticia de un portal de clientes, mejoraremos requisitos vagos y añadiremos una lista práctica a Definition of Done & AC de Power Pack. No necesitas un formato especial para empezar. Bastan condiciones y resultados claros.

¿Qué son los criterios de aceptación?

Los criterios de aceptación describen las condiciones que debe cumplir un trabajo concreto para ser aceptado. Se centran en el resultado esperado de ese elemento. Atlassian los distingue de la definición de terminado, que describe el estándar de calidad más amplio del trabajo completado. Consulta la guía de criterios de aceptación de Atlassian.

En nuestro ejemplo, «La opción de notificaciones guardada permanece seleccionada cuando el cliente vuelve a iniciar sesión» es un criterio de aceptación. «Se ha revisado la implementación» pertenece a la definición de terminado compartida.

Esa distinción mantiene útil cada lista. Los criterios de aceptación explican si esta funcionalidad hace lo que acordó el equipo. La definición de terminado explica si el trabajo cumple el estándar más amplio de finalización del equipo.

Ninguna de las listas necesita contener todos los pasos de implementación. «Crear un campo en la base de datos» puede ser una tarea de ingeniería necesaria, pero no indica al cliente o al revisor si la preferencia se comporta correctamente.

Empieza por un resultado para el cliente

Nuestra incidencia ficticia se llama «Permitir que los clientes controlen el correo de resumen semanal». El resultado buscado es que un cliente con sesión iniciada pueda elegir si recibe un resumen semanal sin cambiar los mensajes esenciales de su cuenta.

Antes de escribir los criterios, el equipo acuerda algunas decisiones de alcance. La configuración tiene un botón Save explícito. El cliente solo cambia su propia preferencia. La preferencia afecta a resúmenes que aún no se han puesto en cola. Los mensajes ya en cola quedan fuera de la regla de entrega de esta incidencia.

Estos detalles son inventados para el ejemplo. Tu equipo debe decidir el comportamiento real en lugar de copiarlos como requisitos de producto.

Una breve nota de alcance puede evitar que una lista larga cargue con todo el contexto. En la descripción de Jira, el equipo registra que esta incidencia cubre una preferencia en la página de configuración de la cuenta. Elegir días de entrega, cambiar direcciones de correo y gestionar preferencias de otros clientes son trabajos separados.

Ahora los criterios pueden centrarse en los resultados que determinan si este cambio concreto funciona.

Escribe primero el recorrido habitual

Empieza por la experiencia que esperas que siga la mayoría de los clientes. Expresa la condición inicial, la acción y el resultado observable con lenguaje corriente.

Por ejemplo: «Cuando un cliente con sesión iniciada desactiva los resúmenes semanales y guarda correctamente, al volver a abrir la configuración de la cuenta los resúmenes aparecen desactivados». Un revisor puede crear el estado inicial, realizar la acción e inspeccionar el resultado.

Esa frase es más útil que «Las preferencias se guardan correctamente». Especifica qué preferencia cambia, cuándo surte efecto el cambio y cómo puede comprobarse.

El equipo también necesita el sentido inverso. Un control que desactiva los resúmenes correctamente pero no permite activarlos está incompleto. Escribe un criterio separado cuando el comportamiento inverso merezca su propia verificación.

No fuerces resultados no relacionados dentro de una sola entrada. Guardar, manejar con teclado, entregar correos y gestionar errores pueden ser importantes, pero un criterio enorme dificulta mostrar qué parte sigue necesitando atención.

Añade casos de fallo y de límite

El recorrido habitual supone que el guardado funciona. Pregunta qué debe ver el cliente cuando esa suposición sea falsa.

Nuestro equipo elige esta regla: si falla la solicitud de guardado, la página muestra un error y no muestra una confirmación de éxito. Al volver a abrir la página, se mantiene la preferencia guardada anteriormente. Esto proporciona al revisor un caso de fallo concreto que probar en el entorno de pruebas del equipo.

Después, examina el límite de la funcionalidad. La configuración del resumen semanal no debe impedir un correo de restablecimiento de contraseña. La elección del cliente también debe persistir tras una nueva sesión. Son cuestiones diferentes y reciben criterios separados.

Evita escribir «Se gestionan todos los casos límite». Identifica los casos que importan. Una conversación útil suele comenzar con tres preguntas: ¿qué puede fallar?, ¿qué debe permanecer sin cambios?, ¿qué ocurre más adelante?

Si el equipo no puede acordar un resultado esperado, registra la decisión pendiente antes de avanzar demasiado en la implementación. Una pregunta sin responder no se convierte en un criterio utilizable simplemente por incluirla en una lista.

Un ejemplo desarrollado de lista de criterios de aceptación

Este es el primer borrador completo de la incidencia ficticia. Cada entrada describe un resultado que el equipo puede verificar por separado.

• Al abrir la configuración de la cuenta se muestra la preferencia de resumen semanal actualmente guardada del cliente.
• Después de desactivar los resúmenes semanales y guardar correctamente, al volver a abrir la configuración de la cuenta la preferencia aparece desactivada.
• Después de activar los resúmenes semanales y guardar correctamente, al volver a abrir la configuración de la cuenta la preferencia aparece activada.
• Después de guardar correctamente, cerrar sesión y volver a iniciarla conserva la preferencia guardada.
• Si falla el guardado, se muestra un error, no aparece confirmación de éxito y al volver a abrir la configuración se muestra la preferencia guardada anteriormente.
• Un cliente con la preferencia desactivada no recibe ningún resumen semanal puesto en cola después del guardado correcto.
• Un cliente con la preferencia activada sigue siendo elegible para el siguiente resumen semanal según las reglas de programación existentes.
• Desactivar los resúmenes semanales no impide que ese cliente reciba un correo solicitado de restablecimiento de contraseña.

Las entradas de entrega dependen de la decisión de alcance sobre los mensajes en cola. El equipo registra ese contexto junto a la incidencia para que el revisor no suponga que la configuración retira correos que ya se están enviando.

Estos criterios también necesitan un método viable de verificación. Para el comportamiento de entrega, el equipo identifica cómo activar u observar un resumen en su entorno de pruebas. Un criterio puede estar claramente redactado y ser difícil de verificar si nadie tiene acceso a la cuenta o a las pruebas de entrega necesarias.

Mejora los criterios vagos antes de añadirlos

Una revisión rápida de la redacción suele evitar desacuerdos más largos después. Lee cada entrada y pregunta si dos personas podrían interpretar el éxito de forma diferente.

El último ejemplo no demuestra por sí solo la usabilidad. Sustituye una frase vaga por una comprobación útil y limitada. Los objetivos de usabilidad más amplios pueden necesitar investigación o varias observaciones acordadas.

Ten cuidado también con la precisión inventada. Añadir un requisito de respuesta en dos segundos parece medible, pero crea un compromiso real. Acuerda las condiciones y el motivo de un umbral de rendimiento antes de incluirlo.

Añade los criterios a Power Pack

Abre la incidencia de Jira y localiza la tarjeta Definition of Done & AC. Selecciona la pestaña Acceptance Criteria. Su lista está separada de Definition of Done, así que comprueba la pestaña seleccionada antes de introducir contenido.

Para añadir un criterio, escribe su título y selecciona Add o pulsa Intro. Utiliza títulos concisos que conserven el resultado esperado. Si un criterio necesita mucho contexto, mantenlo en la descripción de Jira o en la documentación enlazada del equipo.

Para varias entradas, selecciona Bulk Import y pega una lista Markdown con viñetas. Puedes copiar las entradas del ejemplo anterior colocando un guion y un espacio delante de cada una. También se admiten listas Markdown con casillas de verificación.

Revisa las entradas resultantes después de importar. La acción añade contenido a la lista actual, así que importar de nuevo la misma lista puede crear entradas ya presentes. Las casillas Markdown marcadas llegan como completadas; empieza con entradas sin marcar salvo que los resultados de la incidencia actual se hayan verificado realmente.

Si una entrada es incorrecta, revisa la nueva redacción con el equipo, añade la entrada corregida y elimina la obsoleta mediante su solicitud de confirmación. Mantén clara la conversación de apoyo de la incidencia cuando un cambio afecte al alcance acordado.

Revisa los resultados antes de marcarlos como completados

Antes de implementar, pide a alguien que participe en la verificación que repase los criterios propuestos. Puede detectar condiciones iniciales ausentes o un resultado que no pueda observarse con la configuración de pruebas disponible.

Después de implementar, verifica cada resultado y registra las pruebas mediante el proceso habitual de Jira o documentación del equipo. Selecciona el botón Done de un elemento cuando se haya superado el resultado acordado. Seleccionarlo de nuevo lo devuelve a pendiente si un hallazgo posterior reabre la comprobación.

Por ejemplo, la preferencia puede sobrevivir a una recarga de página pero restablecerse tras un nuevo inicio de sesión. El criterio de reapertura de página puede superarse mientras el de persistencia entre sesiones sigue incompleto. Las entradas separadas conservan esa distinción útil.

Power Pack sigue la finalización de la lista; no ejecuta las pruebas ni determina automáticamente quién las revisó. Si la revisión necesita una verificación atribuida a una persona o un resultado fechado, registra esos detalles explícitamente en tu proceso habitual.

Utiliza ambos recuentos sin confundirlos con pruebas

Acceptance Criteria y Definition of Done muestran sus propios recuentos de elementos completados y totales. El indicador de preparación muestra Ready for Release solo cuando ambas listas tienen contenido y todas sus entradas están completadas. En caso contrario, muestra In Verification.

Ese es un resumen del estado de la lista introducida. No puede demostrar que los criterios cubran todos los comportamientos importantes o que las pruebas de apoyo sean sólidas. Tampoco impone transiciones del flujo de trabajo de Jira ni bloquea integraciones.

Nuestra incidencia de notificaciones podría tener completos los ocho criterios de aceptación mientras la documentación de soporte sigue sin terminar en Definition of Done. Los resultados de la funcionalidad han superado la verificación, pero el acuerdo más amplio de finalización del equipo aún tiene un elemento abierto.

Empieza con una próxima incidencia de Jira. Escribe el resultado para el cliente, acuerda las condiciones y resultados importantes, y añade los criterios a Power Pack junto a la definición de terminado compartida. Revisa la lista con quienes construirán y verificarán el cambio. La ventaja es reducir las suposiciones ocultas tras una frase que al principio parecía evidente.

• Atlassian — ¿Qué son los criterios de aceptación?