Cómo escribir criterios de aceptación excelentes (con ejemplos)
¿Cuántas veces has visto a desarrolladores y testers discutir sobre cómo debería funcionar una determinada funcionalidad? ¿Y qué hay de las caras confundidas de los desarrolladores que no estaban seguros de cómo construir la función que pediste? Ambos son problemas bastante comunes en el mundo del software y, por suerte, tienes una herramienta poderosa en tu arsenal para solucionarlos: los criterios de aceptación.
En esta guía, desglosaré la naturaleza de este formato para redactar requisitos, explicaré su papel en la gestión de productos y te mostraré cómo redactar excelentes criterios de aceptación.
Tabla de contenidos
¿Qué son los criterios de aceptación?
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
¿Cuál es el propósito de redactar criterios de aceptación?
¿Cómo deberían ser unos criterios de aceptación bien escritos?
Formatos comunes de criterios de aceptación
¿Qué son los criterios de aceptación
(y dónde encajan dentro de Agile/Scrum?)
En la metodología Agile, un criterio de aceptación es la unidad más pequeña de un requisito funcional o de diseño que los product managers de Agile (o analistas de negocio) agregan a sus historias para comunicar claramente los diferentes estados y comportamientos de las funcionalidades que el equipo planea construir.
Técnicamente, puedes usar los criterios de aceptación donde quieras. Sin embargo, tradicionalmente forman parte de las historias de usuario, que son componentes de las épicas Agile.
Para entender mejor los criterios de aceptación, primero refresquemos la memoria y veamos los elementos en esta jerarquía y para qué sirve cada uno.
Épicas
Las épicas son tareas que contienen requisitos funcionales y no funcionales de alto nivel de una gran funcionalidad o un grupo de funcionalidades que están relacionadas entre sí. Por lo general, una épica abarca un caso de uso completo para tus clientes y contiene todas las funcionalidades y características subyacentes que necesitas implementar para cubrir dicho caso de uso.
Imagina que formas parte del equipo de producto de Spotify y quieres ampliar el uso de la aplicación añadiendo un nuevo caso de uso para personas que están fuera de casa y no tienen acceso a internet.
Para cubrir este caso de uso, puedes considerar añadir una nueva funcionalidad grande llamada “modo offline para Spotify” y puede convertirse en una épica en tu lista de producto que contenga todos los requisitos generales para permitir que los usuarios escuchen música sin conexión, además de varias historias de usuario con los requisitos de partes específicas de esta función.
Historias de usuario
Las historias de usuario son más pequeñas y representan una sola pieza diferenciada de funcionalidad dentro de la épica. Son partes manejables que el equipo Agile puede comprometerse a entregar dentro de una sola iteración.
Una de las características clave de una historia de usuario es que la funcionalidad que representa debe ser algo completo y potencialmente utilizable.
Por ejemplo, si estás construyendo una app de almacenamiento de archivos en línea y quieres permitir que los usuarios renombren los archivos que han subido, tendrás que trabajar tanto en el frontend (la interfaz y experiencia de usuario para renombrar) como en el backend (guardar el nuevo nombre).
Para que la funcionalidad esté completa y sea utilizable, tendrás que terminar ambas tareas y conectar las partes del frontend y el backend entre sí. Todo esto lo haría tu equipo dentro del alcance de una sola historia de usuario.
Si solo hicieras el trabajo de backend, la tarea en sí no sería una historia adecuada, ya que entregaría algo que no es completo ni utilizable.
Para que el equipo de desarrollo sepa cómo se verá la funcionalidad y cómo debe comportarse, los product owners escribirán criterios de aceptación para esa historia.
Criterios de aceptación de la historia de usuario
Por último, tenemos los elementos más pequeños en la jerarquía de requisitos de producto de software: los criterios de aceptación. Representan escenarios de uso individuales de esa funcionalidad o piezas de información que el equipo de ingeniería considerará importantes al implementar la historia.
En el ejemplo anterior, un criterio de aceptación sería abrir un campo de texto con el nombre del archivo ya completado si el usuario hace clic en el botón ✏️Renombrar del archivo que ha subido.
Definición de hecho (¡sí, es diferente de los criterios de aceptación!)
A veces, los product owners (especialmente aquellos que son relativamente nuevos en este rol de scrum) confunden la definición de hecho con los criterios de aceptación.
La verdad, también me resultó bastante confuso al principio, porque ambos son “criterios para comprobar si una funcionalidad está completa”.
La única diferencia es que la definición de terminado representa la completitud en términos de los procesos de desarrollo del equipo.
Mientras que los criterios de aceptación representan los requisitos funcionales (cómo debe verse y comportarse la funcionalidad).
Esto significa que la definición de terminado será la misma para todas las historias que el equipo esté implementando a menos que decidan hacer cambios durante las retrospectivas. Los criterios de aceptación, por otro lado, son únicos para cada historia, ya que explican la forma en que debe funcionar esa funcionalidad.
Nota: Algunas herramientas de gestión de productos te permiten tener tanto la definición de terminado como los criterios de aceptación en tus historias.
Ahora que recordamos de qué tratan las épicas y las historias, y cómo se relacionan los criterios de aceptación con ellas, pasemos a entender por qué los product owners escriben criterios de aceptación en primer lugar.
¿Cuál es el propósito de escribir criterios de aceptación?
¿Puedo simplemente escribir la descripción de una historia de usuario como yo quiera sin incluir ningún criterio de aceptación? ¿Cuál es el beneficio de escribir criterios de aceptación, de todos modos?
Por supuesto, puedes escribir tus historias como desees. Sin embargo, te recomiendo que utilices los criterios de aceptación como forma de formular tus requisitos, ya que este formato ofrece una amplia variedad de ventajas. Aquí tienes algunas para considerar.
Fomentan el pensamiento orientado al comportamiento
Si optas por el formato BDD para los criterios de aceptación (hablaremos más de esto más adelante), entonces tus criterios de aceptación describirán el recorrido de tus clientes al usar la funcionalidad en cuestión.
La belleza de este enfoque es que alejas tu pensamiento de los requisitos técnicos secos y comienzas a ver la funcionalidad desde el punto de vista del usuario. De este modo, puedes visualizar lo que experimentarán y sentirán al interactuar con tu funcionalidad.
Es muy común que el product owner se dé cuenta de que la funcionalidad que imaginó no es la mejor una vez que la observa desde el punto de vista de sus usuarios.
Yo también he vivido eso en múltiples ocasiones. Por ejemplo, cuando estaba creando los requisitos para un editor de fórmulas matemáticas (formaba parte de un producto SaaS de análisis financiero que estábamos desarrollando en ese entonces), yo quería que el proceso de edición fuera así:
- Un botón de editar junto a la fórmula.
- Al hacer clic en el botón de editar, el campo de la fórmula se vuelve editable y aparecen los botones ✅ Guardar y ❎ Cancelar.
- Al hacer clic en cualquiera de ellos, se salía del modo de edición y aparecía allí la nueva versión guardada o la versión anterior de la fórmula, dependiendo de la selección del usuario.
¿Este comportamiento parece lógico, verdad?
Pues, no hasta que empecé a describir los escenarios de uso de los analistas y encontré un defecto de usabilidad importante. Los analistas suelen ajustar la fórmula haciendo pequeños cambios y observando el resultado del cálculo hasta obtener la fórmula que desean.
La manera en que imaginé la edición sería sumamente molesta para mis usuarios objetivo, ya que tendrían que entrar y salir del modo edición 20 o 30 veces seguidas. Por lo tanto, tan pronto como me di cuenta del error, cambié rápidamente los criterios de aceptación y pedí construir un editor de fórmulas donde se pudieran hacer cambios en tiempo real.
Ayudan a crear una única fuente de verdad
Como "novato" en la gestión de producto, mi mayor reto era comunicar los requisitos del producto a personas de diferentes profesiones o incluso a equipos distintos. El problema era que cada uno los entendía de forma diferente y la comunicación entre ellos se volvía un caos poco claro.
Fue entonces cuando un product manager con experiencia me sugirió que aplicara el concepto de una fuente única de verdad formulando mis requisitos de producto de manera muy clara (esto es algo para lo que la IA en la recopilación de requisitos puede ayudar), comunicándolos a todos y pidiéndoles que basen su trabajo solo en lo que está escrito allí.
Fue un éxito rotundo, ya que todos tenían el mismo entendimiento de cómo debía funcionar la funcionalidad y, si surgían diferencias, recurrían al requisito.
Los criterios de aceptación son una excelente manera de crear una única fuente de verdad, ya que describen la funcionalidad de forma clara y fácil de leer y tienen una alta granularidad (pues deberían cubrir todos los detalles principales de la funcionalidad).
Mejoran la Calidad de las Pruebas de Aceptación
Para los ingenieros de software, los criterios de aceptación funcionan como los requisitos del producto que seguirán al construir la funcionalidad. Para el equipo de calidad, en cambio, los criterios de aceptación tienen algunas ventajas adicionales:
Ayudan a priorizar los casos de prueba. Si tu equipo de pruebas de software tiene muchos casos de prueba para esa funcionalidad y no hay tiempo suficiente para revisarlos todos, priorizarán y ejecutarán primero los escenarios de prueba que coincidan con los criterios de aceptación, ya que describen los flujos de usuario más críticos.
Funcionan como una lista de verificación de aceptación. Este punto es válido tanto para los equipos de QA como para los responsables del producto que necesitan aceptar la funcionalidad. Los criterios de aceptación, como su nombre indica, sirven como lista de comprobación para determinar si la funcionalidad pasa o no. Si uno o más de los criterios de aceptación no se cumplen, el equipo de QA volverá a abrir la historia y pedirá al equipo de ingeniería que agregue la funcionalidad faltante.
En resumen, los criterios de aceptación son herramientas invaluables en manos de los responsables de producto para comunicar correctamente los requisitos. Pero, ¿cómo escribir buenos criterios de aceptación? Déjame ayudarte con eso a continuación.
¿Cómo Deberían Verse unos Criterios de Aceptación Bien Escritos?
La calidad de los criterios de aceptación que redactes tendrá un impacto directo en la calidad de las funcionalidades que entrega tu equipo. Con una comprensión clara de qué construir y cómo probarlo, tu equipo desarrollará la funcionalidad tal como la imaginaste, con el mínimo de contratiempos.
Para destacar al escribir criterios de aceptación, deberás prestar atención a lo siguiente.
Claridad
El pecado número uno que puede cometer un responsable de producto es escribir criterios de aceptación poco claros o vagos. Olvídate de la idea de entendimiento compartido si la gente puede interpretar lo que has escrito de varias formas.
Para ver lo diferente que puede ser, déjame mostrarte un ejemplo.
¿Qué has entendido de esta frase? ¿Puedes decirme cómo va a usar el cajero automático el tipo de tarjeta para decidir si debe autenticar al usuario o no? ¿El cajero va a autenticar al usuario si se cumplen todos estos criterios al mismo tiempo o basta con cumplir solo uno?
Si entregas este criterio de aceptación a tus ingenieros, te inundarán de preguntas y te pedirán que aclares mejor los requisitos. Ahora vamos a mejorarlo.
Mucho mejor, ¿verdad? Con estos criterios de aceptación, hemos respondido también a todas las preguntas anteriores. El cajero automático necesita soportar el tipo de tarjeta que el usuario ha introducido y los tres criterios deben cumplirse al mismo tiempo para que el cajero realice la autenticación.
Consejo profesional: Haz que tus criterios de aceptación sean SMART (específicos, medibles, alcanzables, relevantes, comprobables). Sí, he cambiado el último por "comprobables", ya que es una característica importante de unos criterios de aceptación efectivos.
Legibilidad
Además de evitar la ambigüedad en tus criterios de aceptación, también deberías mantenerlos simples y evitar términos rebuscados o inglés complejo.
Estoy seguro de que tienes un equipo de superestrellas altamente calificadas que puede leer y comprender fácilmente las palabras y frases más complejas y sofisticadas del inglés, ¡pero realmente no quieres desperdiciar su poder cognitivo descifrando tus textos!
Así que, en vez de esto.
Di esto.
¡Supongo que ni siquiera te molestaste en leer por completo el primer criterio de aceptación porque tampoco querías perder tiempo ni esfuerzo mental!
Cobertura de Casos
El diablo está en los detalles. A veces te das cuenta de que has pasado por alto un caso problemático en tu funcionalidad cuando ya es muy tarde en la fase de desarrollo y tienes que abrir una tarea de mejora posterior o incluso rehacerlo todo.
Te suena familiar, ¿verdad?
Cuantos más casos tengas en cuenta desde el principio en tus criterios de aceptación, menor será la probabilidad de que te enfrentes a ese escenario con tus elementos del backlog.
Ahora, echemos un vistazo a los criterios de aceptación a continuación.
¿Ves algo extraño aquí? A primera vista, el requisito es claro: añades la dirección de correo electrónico, haces clic en enviar y la persona obtiene acceso. En realidad, aquí no hemos tenido en cuenta muchos casos:
- Si la dirección de correo electrónico ya está en la lista de usuarios con acceso al documento, quizá deberías mostrar un mensaje de error informando al usuario al respecto.
- Vas a enviar un correo de invitación al usuario, así que podría ser útil mostrar en tu lista compartida si ha aceptado la invitación o no.
- Si no ha aceptado la invitación, tal vez valga la pena agregar un botón de “reenviar invitación”.
También existen casos negativos cuando aclaras el comportamiento de tu funcionalidad ante campos vacíos o si ocurre un error.
Uso Activo de Ayudas Visuales
¿Te quedaron completamente claros los criterios de aceptación que te mostré arriba? Cuando hablé del campo “Añadir personas y grupos”, ¿entendiste con claridad a qué me refería?
A veces, las palabras no son suficientes para aportar claridad de requisitos a tu equipo y es mejor mostrar que explicar. Ahora, déjame mejorar un poco estos criterios de aceptación.
¿Estoy en lo correcto si asumo que entenderías fácilmente a qué me refería con estos criterios de aceptación si vieras la imagen y mis comentarios uno al lado del otro? Apostaría que sí.
Así que eso cubre los “criterios de aceptación” de los criterios de aceptación—ahora vamos a hablar de los diferentes tipos y formatos que los equipos de producto utilizan para ellos.
Formatos Comunes de Criterios de Aceptación
Tengo que ser franco contigo. Rara vez uso el mismo formato en todas mis historias de usuario. La razón es que los distintos formatos de criterios de aceptación son excelentes para distintos casos y no siempre es buena idea obligarte a usar el mismo formato siempre.
Por lo tanto, elijo el formato en función de la historia y del tipo de información que quiero escribir en sus criterios de aceptación.
Ahora veamos algunos de los formatos más comunes y sus ejemplos de criterios de aceptación correspondientes.
Formato BDD
BDD significa Desarrollo guiado por comportamiento y es un marco que fomenta que los miembros del equipo de desarrollo de software y producto definan los requisitos basándose en la forma en que sus usuarios finales interactuarán con la funcionalidad.
Como una forma de redactar los requisitos según el comportamiento del usuario, los criterios de aceptación para BDD siguen este modelo específico:
Dado: La condición previa para el escenario específico del comportamiento del usuario.
Cuando: La acción que realiza el usuario.
Entonces: El resultado de la acción.
Así, si quisieras explicar cómo funciona la opción de retiro en un cajero automático, tus criterios de aceptación se verían así:
El tipo de criterio de aceptación dado/cuando/entonces es excelente cuando deseas fomentar empatía hacia las necesidades del usuario dentro de tu equipo, haciendo hincapié en la perspectiva del usuario.
Formato Lista de Comprobación
A diferencia del BDD (también llamado “formato orientado a escenarios”), este no muestra el punto de vista del usuario final. En cambio, se trata más bien de explicar ciertas reglas que debe seguir la lógica de negocio de la funcionalidad (el nombre alternativo para este formato es “orientado a reglas”). Así es como se ve.
Este formato te será de gran ayuda cuando la lógica que quieras explicar sea compleja, pues te ayuda a dividirla en varias reglas pequeñas más fáciles de entender e implementar.
Formato de Flujo
Probablemente este es el formato que más utilizo.
El formato de flujo es similar al formato BDD, ya que también muestra el punto de vista del usuario. Sin embargo, a diferencia de BDD, no impone una estructura estricta (Dado/Cuando/Entonces). Por lo tanto, eres libre de narrar los pasos que realiza el usuario como prefieras.
Así es como se vería el proceso de registro con este formato.
El formato de flujo será tu mejor opción si quieres generar empatía con el usuario (al igual que con BDD), pero no deseas seguir una estructura estricta.
Mantén a Todos en la Misma Página con Criterios de Aceptación
Los criterios de aceptación son herramientas poderosas en manos de los product owners, ya que les permiten crear una única fuente de verdad y mantener a sus compañeros alineados con su visión para esa funcionalidad.
¡Para más guías como esta y otros grandes recursos para personas de producto, suscríbete a nuestro boletín!
