Hola a todos,
Escribir criterios de aceptación, a pesar de ser un proceso de llegar a un acuerdo sobre lo que se quiere recibir, no deja de ser un reto. En este proceso surgen al menos tres preguntas:
- ¿Hasta cuándo es suficiente detalle?
- ¿Estoy dejando la descripción muy general?
- ¿Qué más debo incluir?
Ante esto, generalmente, a los Product Owners les digo:
- No te preocupes, que si falta detalle, los developers te lo recordarán.
- Si olvidaste algo, es porque aún no es importante.
Aún así, el pedido que constantemente recibo es:
"¿Podrías escribir una guía para hacer criterios de aceptación?"
Considerando que lo anterior lo he respondido de forma particular, voy a cambiar mi aproximación y hacerlo por medio de este artículo que, con seguridad, iré engrosando en la medida que la retroalimentación y la experiencia vayan llegando.
¿Qué son los criterios de aceptación?
Los criterios de aceptación son las condiciones que una historia de usuario debe cumplir para considerarse completada cuando es desarrollada y desplegada por el equipo. Funcionan como una guía para los desarrolladores y testers, asegurando que lo que se construye es realmente lo que el negocio necesita.
Es de considerar que el formato original de las historias de usuario no incluía los criterios de aceptación (1), y aunque no hay un acuerdo sobre quien los incluyó, Ron Jeffries hace referencia tácita a ellos en su artículo sobre las tres C (Card - Conversation- Confirmation) (2):
"Al comienzo de la iteración, el cliente comunica a los programadores lo que desea y les dice cómo confirmará que han hecho lo que se necesita. Define las pruebas de aceptación que se utilizarán para demostrar que la historia se ha implementado correctamente".(2)
No se habla de un formato específico, incluso se sugiere el uso de ejemplos para que estos sean más claros, algo que al final incluyó Behavior Driven Development (BDD) (3).
No confundir con la Definition of Done (DoD). Mientras que los criterios de aceptación son específicos para una historia de usuario, la Definición de Terminado es un estándar general del equipo para determinar cuándo una historia está terminada desde un punto de vista técnico y de calidad.
¿Por qué son clave en un desarrollo ágil? (4)
Los criterios de aceptación cumplen un papel fundamental en la comunicación entre los equipos de desarrollo y los stakeholders. Algunas razones por las que son esenciales incluyen:
- Evitan malentendidos: Reducen la ambigüedad y ayudan a alinear expectativas.
- Mejoran la calidad del producto: Definen el mínimo aceptable para el negocio.
- Facilitan la prueba y validación: Los testers pueden usarlos para diseñar pruebas.
- Permiten la automatización: Son la base para la creación de pruebas automatizadas.
- Pueden contener ejemplos que van a guiar a los desarrolladores: Basados en los ejemplos proporcionados, los desarrolladores encontrarán como cumplir con lo que se espera de la fucionalidad.
Cómo aceptar la funcionalidad con el usuario durante la escritura de historias de usuario
Validar la historia de usuario antes de escribir los criterios de aceptación
- Explicar la historia de usuario en términos simples y preguntar:
- “¿Esta historia realmente cubre tu necesidad?”
- Preguntar si falta algo en la descripción de la historia.
- Asegurar que la historia esté escrita en el lenguaje del usuario, no en lenguaje técnico. No incluyas llamado a bases de datos, nombres de tablas, etc.
Involucrar al usuario en la definición de criterios de aceptación
- Preguntar cómo espera que funcione la funcionalidad en su día a día.
- Plantear escenarios de uso y validar que cubran sus expectativas.
- Escribir los criterios de aceptación junto con el usuario o validarlos con él antes de finalizar la historia.
Revisar los criterios de aceptación con ejemplos
- Presentar ejemplos de cómo funcionará la funcionalidad basados en los criterios de aceptación y preguntar:
- “Si esto se comporta así, ¿te parecería correcto?”
- “¿Cuáles son los campos que van a viajar en el formulario? ¿Cuáles serán las validaciones asociadas a cada campo?”
- “¿Cuáles son los campos que tendrá el reporte? ¿Tendrá filtros?”
- “¿Cuáles son los mensajes de éxito y de fracaso, según el resultado?”
- “¿La imagen o gráfico será interactivo? ¿Qué comportamientos tendrá?”
- Si usa formato Given-When-Then (más adelante cubriré este aspecto), leer los escenarios y validar con el usuario.
Usar prototipos o bocetos si es necesario
- Si la funcionalidad es visual, mostrar wireframes o pantallas para confirmar que la historia refleja lo que el usuario espera.
Obtener aprobación antes de llevarla a desarrollo
- Preguntar directamente: “Si construimos esto con base en estos criterios de aceptación, ¿estarías satisfecho?”
- Si hay dudas o cambios, refinarlos antes de que el equipo empiece a desarrollarla.
- Preguntas adicionales para descubrir criterios de aceptación
Si quieres mejorar la identificación de criterios de aceptación, aquí tienes más preguntas que puedes hacer al usuario o al equipo:
- Sobre el objetivo de la historia
- ¿Cuál es el problema exacto que queremos resolver con esta historia?
- ¿Cómo sabremos si la funcionalidad realmente cumple su propósito?
- ¿Hay métricas o indicadores que podrían ayudarnos a medir el éxito?
- Sobre los escenarios clave
- ¿En qué situaciones usarías esta funcionalidad?
- ¿Cuál es el flujo ideal desde tu perspectiva?
- ¿Existen variantes o excepciones que debamos considerar?
- Sobre las reglas de negocio
- ¿Existen restricciones específicas para esta funcionalidad?
- ¿Qué pasa si el usuario introduce datos incorrectos?
- ¿Hay algún comportamiento especial que deba seguir la funcionalidad en ciertos casos?
- Sobre la experiencia de usuario
- ¿Qué tan rápido esperas que responda el sistema?
- ¿Cómo te gustaría recibir la confirmación de que la acción se completó?
- ¿Prefieres una notificación visual, un correo, o algún otro mecanismo?
- Sobre seguridad y accesos
- ¿Todos los usuarios deberían poder acceder a esta funcionalidad?
- ¿Necesitamos permisos o restricciones especiales?
- Sobre el manejo de errores y excepciones
- ¿Qué pasa si el sistema no puede completar la acción?
- ¿Cómo debería informarse al usuario en caso de error?
- Sobre la integración con otros sistemas
- ¿Esta funcionalidad afecta o depende de otros módulos o sistemas?
- ¿Qué datos necesitamos capturar o enviar a otras áreas del sistema?
Elementos esenciales de un buen criterio de aceptación
Para que los criterios de aceptación sean efectivos, deben cumplir con estas características:
- Claridad y precisión: No deben dejar espacio a interpretaciones.
- Independencia de implementación: No describen cómo hacerlo, sino qué resultado se espera.
- Testabilidad: Deben ser verificables con pruebas manuales o automatizadas.
- Alineación con las necesidades del usuario: Siempre deben responder a lo que el usuario final necesita.
Formatos comunes para escribir criterios de aceptación
Formato tradicional
Es el más simple: una lista de condiciones que deben cumplirse.
Ejemplo:
Historia de usuario:
Yo como usuario quiero poder restablecer mi contraseña para acceder a mi cuenta en caso de olvido.
Criterios de aceptación:
- El usuario debe recibir un correo con un enlace de restablecimiento.
- El enlace debe expirar en 30 minutos.
- La nueva contraseña debe cumplir con requisitos de seguridad.
Formato Given-When-Then (Gherkin)
Este formato, popular en BDD (Behavior Driven Development), ayuda a describir escenarios de manera estructurada:
- Given: Estado inicial.
- When: Acción del usuario.
- Then: Resultado esperado.
Ejemplo:
Given que el usuario olvidó su contraseña,
When ingresa su correo en la opción “Olvidé mi contraseña” y presiona enviar,
Then debe recibir un correo con un enlace de restablecimiento.
Este enfoque facilita la automatización de pruebas con herramientas como Cucumber.
Errores comunes al redactar criterios de aceptación
- Ambigüedad: Si no es claro, cada persona lo interpretará de manera diferente. Aunque invitan a la conversación en fases tempranas, próximos al desarrollo pueden convertirse en una fuente de incertidumbre, ejemplo: si la transacción no es exitosa se deberá confirmar al usuario. Surgen varias preguntas con lo anterior ¿Cómo? ¿Qué mensaje? ¿A través de que medios? ¿Proporcionaremos al usuario alguna forma de hacer reclamos?
- Demasiado técnico: No deberían describir cómo implementarlo, sino qué resultado se espera.
- No validarlos con el equipo: Deben ser revisados en sesiones de refinamiento del backlog.
Mejores prácticas para escribir criterios de aceptación efectivos
- Involucrar a todas las partes interesadas: No es solo tarea del Product Owner, los desarrolladores y testers también deben participar.
- Refinarlos en sesiones de backlog refinamiento con el equipo: Asegurar que sean claros antes de iniciar el desarrollo.
- Hacerlos testables: Si no se pueden probar, probablemente no están bien escritos.
- Utilizar el lenguaje del usuario final: Evitar tecnicismos innecesarios.
Cómo automatizar pruebas basadas en criterios de aceptación
Los criterios de aceptación bien definidos pueden traducirse directamente en pruebas automatizadas. Algunas herramientas que permiten hacer esto incluyen:
- Cucumber (BDD, Given-When-Then).
- Selenium (Pruebas UI basadas en escenarios).
- JUnit / TestNG (Pruebas unitarias automatizadas).
Esto permite que el equipo valide rápidamente si una historia cumple con los requerimientos sin depender exclusivamente de pruebas manuales.
Checklist final para validar criterios de aceptación
- Historia de usuario validada con el usuario o stakeholder.
- Criterios de aceptación basados en necesidades reales. Evita el desperdicio, es decir, poner criterios que no serán usados.
- Ejemplos o escenarios de uso confirmados.
- Información que se capturará o que retornará la funcionalidad, y el nombre de sus campos.
- Reglas de negocio y restricciones documentadas.
- Casos de error y manejo de excepciones definidos.
- Aprobación del usuario antes de pasar a desarrollo.
Nota importante: Un buen criterio de aceptación se puede convertir en un caso de prueba, directamente. Si el tester puede escribir una prueba automatizada o manual a partir de él, es una señal de que está bien definido.
Y si quedas con muchos criterios de aceptación
Cerrando
Escribir buenos criterios de aceptación es clave en el desarrollo ágil. Mejoran la comunicación, reducen malentendidos y permiten entregar software de mejor calidad.
Si en tu equipo todavía no los documentan formalmente, este es un buen momento para comenzar.
Notas. Aclaraciones Comentarios
- De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP) - Clic aquí.
- XP esencial: Tarjeta, Conversación, Confirmación - Clic aquí.
- What's in a Story? - Clic aquí.
- En este momento de la historia existe un boom sobre la Inteligencia Artificial y lo que puede proporcionarnos el uso de agentes; es posible que en el futuro cercano muchas o todas las tareas de desarollo y testing sean ejecutadas por Agentes de IA. Amanecerá y veremos.
- La historia de las historias de usuario - Clic aquí.
