Criterios de aceptación: cómo redactarlos

Los criterios de aceptación constituyen la prueba de aprobación o rechazo de una historia, que se redacta antes de comenzar el trabajo: los formatos que funcionan, ejemplos concretos y en qué se diferencian de la definición de «terminado».

Los criterios de aceptación son las condiciones que debe cumplir una historia para ser aceptada: una prueba de «aprobado/suspenso» que se redacta antes de que nadie comience a programar. No se conceden puntos parciales: o se cumple cada uno de ellos o no se cumple. Describen lo que debe hacer el resultado, no cómo construirlo. Y son una prueba, no una segunda descripción de la funcionalidad. Si puede cumplirlos con un código que no resuelve el problema, no son criterios de aceptación, sino requisitos encubiertos.

Cada historia conlleva una pregunta implícita: ¿cómo sabremos que está terminada? Los criterios de aceptación responden a esa pregunta de forma explícita, antes de que comience el trabajo. Si se definen correctamente, la estimación resulta más sencilla, la demostración se elabora por sí sola y el concepto de «terminado» deja de ser objeto de negociación. Si se definen de forma imprecisa, se habrá lanzado una funcionalidad sobre la que nadie se había puesto de acuerdo.

Qué son los criterios de aceptación y qué no son

Un buen criterio de aceptación es aquel que se le podría entregar a un probador que nunca haya asistido a su reunión de refinamiento y que, aun así, supiera exactamente qué debe comprobar. Describe un resultado que el usuario puede observar, no la implementación que lo genera. «Utilizar una caché de Redis» no es un criterio de aceptación, sino una solución. «Los resultados se cargan en menos de un segundo para una tabla de 10 000 filas» sí lo es, porque cualquiera puede comprobarlo y nadie tiene que leer el código para hacerlo.

Tampoco se trata de una lista de deseos. Cada criterio debe poder refutarse. Si una afirmación no puede verificarse —«la página es intuitiva», «el rendimiento es bueno»—, no es un criterio, sino una esperanza. Elimínela o haga que sea medible.

Los dos formatos que funcionan

Utilice el formato Given/When/Then para comportamientos que dependan del estado, y una simple lista de verificación para un conjunto de requisitos independientes. La mayoría de los equipos recurren al formato Given/When/Then para todo; evítelo. Una lista de verificación es más rápida de leer y más difícil de rellenar con contenido superfluo cuando la historia se reduce simplemente a «estas cinco cosas deben cumplirse».

Dado que / Cuando / Entonces

Partiendo de un estado inicial, cuando el usuario realiza una acción, el sistema responde de una manera concreta. Este formato demuestra su utilidad al obligarle a nombrar los tres elementos —la precondición, el desencadenante y el resultado observable—, que es precisamente lo que omite un criterio impreciso.

Ejemplos de criterios de aceptación

Una historia de inicio de sesión, redactada según el formato «Dado que/Cuando/Entonces»:

  • Dado que un usuario registrado se encuentra en la página de inicio de sesión, cuando introduce una dirección de correo electrónico y una contraseña correctas, entonces accede a su panel de control.
  • Si un usuario registrado introduce una contraseña incorrecta tres veces, entonces la cuenta se bloquea durante 15 minutos y se le muestra el tiempo que queda.
  • Dado que se trata de la página de inicio de sesión, cuando el campo de correo electrónico está vacío, entonces el botón de envío aparece desactivado.

Una guía sobre «cómo filtrar la tabla de resultados», redactada a modo de lista de comprobación:

  • El filtro se aplica al seleccionar; no hay ningún botón independiente de «Aplicar».
  • Los dos filtros se combinan con «Y», no con «O».
  • Al borrar todos los filtros, se restablece la lista completa sin ordenar.
  • Un conjunto de resultados vacío indica el estado «sin coincidencias», no una tabla en blanco.

Fíjese en lo que ambos omiten: la base de datos, el marco de trabajo y los nombres de los componentes. Indican lo que recibe el usuario, no cómo se lo va a proporcionar usted, y cada línea es un elemento que un evaluador puede aprobar o rechazar sin necesidad de hacerle ninguna pregunta.

Cómo redactar criterios de aceptación

  • Redáctelas durante el refinamiento del backlog, junto con el equipo —no por su cuenta, ni después—.
  • Un resultado observable por línea. Si en una línea aparece un «y» que cumple una función concreta, se trata de dos criterios.
  • Identifique la ruta no deseada. El estado vacío, el tiempo de espera agotado, la entrada incorrecta: ahí es donde se esconde el esfuerzo.
  • Céntrese en el comportamiento, no en el diseño. La maqueta se ocupa de la maquetación; los criterios se centran en lo que debe cumplirse.
  • Deténgase más o menos a las cinco.

¿A partir de cuántos criterios de aceptación se considera que son demasiados?

Aproximadamente cinco. No porque exista una regla, sino porque una historia que requiera diez condiciones distintas y comprobables contiene diez partes de valor distintas, lo que significa que se trata de varias historias que se hacen pasar por una sola. Cuando la lista se alarga, los criterios de aceptación son el punto de división.

Clasificación según los criterios de aceptación

Si una historia tiene más de cinco criterios de aceptación, estos suelen constituir la división. La lista es un backlog que hace las veces de lista de comprobación.

Los criterios de aceptación existen para describir una historia. No deben ser la historia en sí. Cuando la lista se alarga —seis, ocho, diez puntos—, a menudo el equipo ha llevado a cabo la división sin darse cuenta. Cada criterio es una pequeña parte que el equipo podría entregar, mostrar en una demostración y dar por concluida. Tratar toda la lista como un único compromiso obliga al equipo a asumir todo de una vez, lo cual constituye la peor combinación de volumen y riesgo que se le puede asignar a alguien en un sprint.

Para desglosarlo, analice cada criterio y hágase la pregunta que se haría con cualquier historia de usuario: ¿lanzaría el equipo esto por sí solo? ¿Se beneficiaría el usuario de ello por sí solo? ¿Se podría hacer una demostración? Los puntos que superen esa prueba son historias. Los puntos que no superan esa prueba suelen pertenecer a una de las historias seleccionadas: forman parte del alcance de una historia que ya ha separado, no son un trabajo independiente.

Donde esto falla es en los criterios estrechamente vinculados: «el formulario valida los datos introducidos y los guarda en la base de datos y muestra un mensaje de confirmación». Esos tres elementos parecen separables, pero el usuario no obtiene nada si solo se cumple uno de ellos. No se trata de una división por criterios; es una única historia pequeña, y las viñetas no son más que una muestra de la minuciosidad del equipo.

Criterios de aceptación frente a requisitos

Un requisito indica qué hay que desarrollar. Un criterio de aceptación indica cómo se sabrá que se ha desarrollado lo correcto. «Los usuarios pueden restablecer su contraseña» es un requisito, y puede cumplirse con un proceso tan defectuoso que nadie lo complete. «Un usuario que solicite un restablecimiento recibe un correo electrónico en un plazo de dos minutos cuyo enlace caduca al cabo de una hora» es un criterio de aceptación, ya que se trata de una prueba en la que el proceso defectuoso falla. Los requisitos delimitan el alcance del trabajo; los criterios lo regulan.

Criterios de aceptación frente a la definición de «terminado»

Estos conceptos se confunden constantemente, pero la distinción es sencilla: los criterios de aceptación se aplican por historia; la definición de «terminado» es global. Los criterios anteriores describen lo que la historia de inicio de sesión debe hacer específicamente. La definición de «terminado» —probado, revisado el código, documentado e implementado en el entorno de pruebas— se aplica a todas las historias que el equipo entrega. Una historia puede cumplir sus criterios de aceptación y, aun así, no estar terminada, ya que «funciona según lo especificado» y «listo para su lanzamiento» son requisitos distintos. Se necesitan ambos.

Puntos de historia frente a criterios de aceptación

Los criterios de aceptación describen el resultado: lo que debe cumplirse para que la historia se considere entregada. Los puntos de historia describen el camino: el volumen de trabajo que hay entre «aún no disponemos de esto» y «se cumplen los criterios». Se trata de dos ejes distintos. Confundirlos da lugar a criterios cuantificados, lo cual carece de sentido, o a estimaciones de puntos sin criterios que las respalden, lo cual es una mera ilusión.

¿Añadir un criterio modifica la estimación? A veces. Un criterio que pone de manifiesto un trabajo oculto —«debe ser accesible para lectores de pantalla»— suele hacerlo, ya que identifica un esfuerzo que antes era implícito. Un criterio que simplemente aclara una suposición ya existente —«debe funcionar en Chrome y Safari», cuando esos siempre han sido los navegadores compatibles— no debería hacerlo. El orden es importante: primero los criterios, luego los puntos. Realizar una estimación antes de que los criterios estén claros equivale a estimar antes del refinamiento, y es la causa más habitual de que las votaciones se dispersen.

Redacte la prueba antes de empezar a trabajar. Si un criterio no puede fallar, no es un criterio; y si tiene más de cinco, probablemente se trate de más de una historia.

Preguntas frecuentes

¿Qué son los criterios de aceptación?

Los criterios de aceptación son las condiciones que debe cumplir una historia para ser aceptada: una prueba de «aprobado/suspenso» que se establece antes de comenzar el trabajo. Describen lo que debe hacer el resultado, no cómo se debe construir, y no hay puntuación parcial: cada criterio se cumple o no se cumple.

¿Cómo se redactan los criterios de aceptación?

Redacte cada una de ellas como si fuera a entregársela a un evaluador que nunca haya visto la historia. Utilice la estructura «Dado que/Cuando/Entonces» para los comportamientos que dependan del estado, o una simple lista de verificación para un conjunto de requisitos independientes. Asegúrese de que sean comprobables, céntrese en los resultados y limítese a unas cinco; si supera ese número, estará ante varias historias.

¿Cuál es la diferencia entre los criterios de aceptación y los requisitos?

Los requisitos indican qué hay que desarrollar; los criterios de aceptación indican cómo se sabrá que está bien. Un requisito puede cumplirse mediante un código que no dé en el clavo. Un criterio de aceptación es una prueba: si se supera, esa parte de la historia está terminada; si se puede superar sin resolver el problema del usuario, se trata de un requisito encubierto.

¿Cuál es la diferencia entre los criterios de aceptación y la definición de «terminado»?

Los criterios de aceptación se establecen por cada historia: describen lo que debe cumplir esa historia en concreto. La definición de «terminado» es una lista de comprobación global que se aplica a todas las historias (probada, revisada, documentada, implementada). Una historia puede cumplir sus criterios de aceptación y, aun así, no considerarse terminada si no supera la fase de aprobación por parte de todo el equipo.

¿Quién redacta los criterios de aceptación?

El responsable del producto es el encargado de ellos, pero se redactan junto con el equipo durante la fase de refinamiento. El responsable del producto define el resultado; los ingenieros y los evaluadores sacan a la luz los casos extremos. Los criterios de aceptación redactados de forma aislada, a posteriori, son los que pasan por alto el caso que falla en producción.

Lecturas relacionadas