Criterios de Aceptación en Scrum: la clave para un ‘Done’ claro y sin ambigüedades

¿Buscas una respuesta rápida?

Si buscas una respuesta rápida, los criterios de aceptación son condiciones específicas y medibles que una funcionalidad debe cumplir para considerarse “terminada” y aceptada por el Product Owner. Son el puente directo entre lo que se pide y lo que se entrega, fundamentales para evitar malentendidos, guiar al equipo de desarrollo y asegurar la calidad del producto final. A diferencia de la Definición de Hecho (DoD), que es un estándar global de calidad para todo el incremento, los criterios de aceptación son únicos y específicos para cada historia de usuario. Se definen en colaboración, idealmente durante el refinamiento del Backlog, y son la base para las pruebas y la validación final de cada entrega. Si deseas profundizar te invitamos a leer el artículo completo.

---

El papel crucial de los criterios de aceptación en Scrum

En el corazón de cada proyecto ágil late la promesa de entregar valor de forma incremental. Sin embargo, para que esa promesa sea una realidad tangible, necesitamos una comprensión compartida y precisa de qué significa “terminado”. Es aquí donde los criterios de aceptación se revelan como una herramienta indispensable: son las condiciones específicas y medibles que una funcionalidad debe cumplir para ser considerada completa y correcta desde la perspectiva del cliente.

No son meras descripciones de lo que una característica podría hacer; son la lista de verificación inequívoca que utilizamos para validar que la funcionalidad no solo opera como se espera, sino que satisface la necesidad real para la que fue concebida. Funcionan como un contrato transparente entre el Product Owner (quien representa la voz del cliente y los stakeholders) y el equipo de desarrollo.

Más allá de un requisito: el puente hacia el “Done”

Mientras que una historia de usuario describe una funcionalidad desde la perspectiva del usuario (por ejemplo, “Como usuario, quiero poder iniciar sesión en el sistema”), los criterios de aceptación desglosan esa funcionalidad en pasos concretos y verificables. Retomando el ejemplo del inicio de sesión, los criterios podrían especificar: “El usuario debe poder iniciar sesión con credenciales válidas”, “El sistema debe mostrar un mensaje de error si las credenciales son incorrectas”, “El usuario debe ser redirigido a la página principal después de un inicio de sesión exitoso”.

Esta granularidad transforma una aspiración general en una serie de expectativas que se pueden probar rigurosamente. Son el “qué” exacto que debe lograrse para que la historia de usuario evolucione de una idea a un elemento verdaderamente “Done” (Terminado) dentro del Sprint.

La importancia de la claridad para el equipo y el cliente

La ambigüedad en los requisitos es, lamentablemente, una de las principales causas de retrabajo, retrasos y frustración en los proyectos. Los criterios de aceptación mitigan este riesgo al proporcionar:

• Claridad para el equipo de desarrollo: El equipo sabe con exactitud qué construir y cuándo puede considerar que ha cumplido cabalmente con el requisito. Esto elimina la “adivinación” y reduce drásticamente las interpretaciones subjetivas.
• Claridad para el Product Owner: Le permite al Product Owner verificar con precisión si la funcionalidad entregada se alinea con su visión y las expectativas de los stakeholders.
• Fundamento sólido para las pruebas: Sirven como la base directa para la creación de casos de prueba, ya sean manuales o automatizados. Si un criterio no puede ser probado, es una señal clara de que no está bien definido.
• Mejora de la comunicación: Fomentan un diálogo rico y constructivo durante el refinamiento del Backlog y la planificación del Sprint, asegurando que todos los involucrados compartan una misma comprensión unívoca del trabajo.

En síntesis, los criterios de aceptación son el faro que guía al equipo hacia un “Done” significativo y sin ambigüedades, garantizando que cada incremento de producto entregado realmente aporte el valor esperado.

Criterios de aceptación vs. Definición de Hecho (DoD): ¿Cuál es la diferencia?

Aunque a menudo se confunden, los criterios de aceptación y la Definición de Hecho (DoD) son conceptos distintos pero complementarios en Scrum. Ambos buscan la claridad sobre cuándo algo está “terminado”, pero operan en diferentes niveles.

Alcance y propósito de cada uno

Los criterios de aceptación son específicos para cada historia de usuario. Detallan las condiciones que esa funcionalidad particular debe cumplir para ser aceptada por el Product Owner. Responden a la pregunta: “¿Cómo sé que esta característica específica hace lo que se supone que debe hacer?”. Son únicos para cada elemento del Backlog de producto.

La Definición de Hecho (DoD), por otro lado, es un conjunto de estándares de calidad y completitud aplicables a todos los incrementos de producto. Es una lista de verificaciones que cada incremento debe cumplir antes de poder ser considerado “Done” y potencialmente liberable. Responde a la pregunta: “¿Cómo sé que este incremento está listo para ser entregado?”. La DoD es consistente para todo el equipo Scrum y puede incluir elementos como: “código revisado”, “pruebas unitarias pasadas”, “integrado con el sistema principal”, “documentación actualizada”, “desplegado en entorno de staging“.

Cómo se complementan para la calidad del producto

Piensa en la DoD como la “línea de base de calidad” global del equipo, y los criterios de aceptación como las “pruebas específicas de funcionalidad” para cada historia de usuario. Un incremento solo está verdaderamente “Done” si ha cumplido con todos sus criterios de aceptación individuales Y con todos los elementos de la Definición de Hecho.

• Si una funcionalidad cumple sus criterios de aceptación pero no pasó por la revisión de código (parte de la DoD), no está “Done”.
• Si el código se revisó y las pruebas unitarias pasaron (parte de la DoD), pero la funcionalidad no satisface lo que el usuario esperaba (fallando en un criterio de aceptación), tampoco está “Done”.

Ambos elementos son cruciales para construir un producto de alta calidad, predecible y transparente. La DoD asegura la calidad del proceso de desarrollo, mientras que los criterios de aceptación aseguran la calidad funcional del resultado.

¿Quién define los criterios de aceptación y cuándo?

La definición de los criterios de aceptación es un ejercicio colaborativo, pero con un rol principal claramente definido en Scrum.

El rol del Product Owner y la colaboración del equipo

El Product Owner es el principal responsable de proponer y validar los criterios de aceptación. Representa la voz del cliente y debe articular claramente qué espera del producto. Sin embargo, no los define en aislamiento. La forma más efectiva de crearlos es a través de una colaboración activa con el equipo de desarrollo y, en ocasiones, con los stakeholders relevantes.

Durante las sesiones de refinamiento del Backlog (anteriormente conocidas como “Grooming”), el Product Owner presenta una historia de usuario. Es en este momento cuando el equipo de desarrollo, con su conocimiento técnico, puede hacer preguntas clave sobre la implementación, los casos de borde, los mensajes de error y las posibles limitaciones. Este diálogo es fundamental para desglosar la historia en criterios específicos, medibles y viables. El equipo puede sugerir criterios técnicos que el Product Owner quizás no había considerado, garantizando que la funcionalidad no solo cumpla con la necesidad de negocio, sino que también sea técnica y operativamente sólida.

El momento ideal para su definición: Refinamiento del Backlog

La definición de los criterios de aceptación ocurre principalmente durante las sesiones de refinamiento del Backlog. Estas sesiones no son eventos formales de Scrum, sino actividades continuas en las que el Product Owner y el equipo de desarrollo colaboran para añadir detalles, estimaciones y ordenar los elementos del Backlog de producto.

Idealmente, los criterios de aceptación deben estar lo suficientemente claros antes de que una historia de usuario sea seleccionada para un Sprint. Esto permite que el equipo de desarrollo entienda el alcance total del trabajo, genere estimaciones más precisas y se comprometa con confianza a entregar un incremento “Done” al final del Sprint. Si los criterios no están claros al inicio del Sprint, es probable que surjan malentendidos y retrabajo.

Formatos efectivos para escribir criterios de aceptación

La forma en que se escriben los criterios de aceptación puede impactar significativamente su claridad y utilidad. Si bien no hay una única “mejor” manera, algunos formatos son ampliamente adoptados por su eficacia.

El estándar Gherkin: Dado-Cuando-Entonces (Given-When-Then)

El formato Gherkin, popularizado por metodologías como BDD (Behavior-Driven Development) o Desarrollo Guiado por el Comportamiento, es una de las formas más claras y estructuradas de escribir criterios de aceptación. Se lee casi como una frase narrativa y se compone de tres partes principales:

• Dado (Given): Describe el estado inicial del sistema o el contexto en el que se encuentra el usuario.
• Cuando (When): Describe la acción o el evento que el usuario o el sistema realiza.
• Entonces (Then): Describe el resultado esperado o el cambio de estado en el sistema después de la acción.

Ejemplo para una historia de usuario “Como usuario, quiero iniciar sesión en la aplicación”:

• Escenario: Inicio de sesión exitoso
  • Dado que estoy en la página de inicio de sesión,
  • Cuando ingreso mi correo electrónico válido “usuario@ejemplo.com” y mi contraseña correcta “MiContraseña123”,
  • Entonces soy redirigido al panel de control de usuario.
• Escenario: Intento de inicio de sesión con credenciales incorrectas
  • Dado que estoy en la página de inicio de sesión,
  • Cuando ingreso mi correo electrónico “usuario@ejemplo.com” y una contraseña incorrecta “ContraseñaErrada”,
  • Entonces se muestra un mensaje de error “Credenciales incorrectas. Por favor, inténtelo de nuevo.”
  • Y permanezco en la página de inicio de sesión.

Este formato es excelente porque es legible tanto para perfiles técnicos como no técnicos, y facilita la automatización de pruebas directamente a partir de los criterios.

Otros formatos (listas, escenarios) y cuándo usarlos

Aunque Gherkin es muy potente, no siempre es necesario. Otros formatos también pueden ser efectivos, dependiendo de la complejidad y la preferencia del equipo:

• Listas de verificación: Simplemente una lista numerada o con viñetas de las condiciones que deben cumplirse.
  • Ejemplo para “Como usuario, quiero agregar un producto al carrito”:
    • El producto se añade al carrito.
    • El total del carrito se actualiza.
    • Se muestra una notificación de éxito.
    • El usuario puede ver el producto en la página del carrito.
• Escenarios de usuario: Describen un flujo de interacción más largo, a menudo con pasos.
  • Ejemplo para “Como usuario, quiero registrarme en la aplicación”:
    1. El usuario navega a la página de registro.
    2. Completa todos los campos obligatorios.
    3. Hace clic en “Registrarse”.
    4. El sistema valida los datos.
    5. Si los datos son válidos, se crea la cuenta y el usuario es logueado automáticamente.
    6. Si los datos son inválidos, se muestran mensajes de error específicos por campo.

La elección del formato debe basarse en lo que sea más claro y funcional para el equipo y el Product Owner. Lo importante es que sean específicos, inequívocos y probables.

Características de unos criterios de aceptación efectivos (SMART para Criterios)

Para que los criterios de aceptación cumplan su propósito de guiar el desarrollo y las pruebas, deben poseer ciertas cualidades. Podemos adaptar el conocido acrónimo SMART para recordar sus características clave:

• Específicos (Specific): Deben describir una condición clara y sin ambigüedades. Evita generalidades como “debe ser fácil de usar” o “debe funcionar bien”. En su lugar, especifica “el botón de enviar debe estar visible en la esquina inferior derecha”.
• Medibles (Measurable): Deben ser cuantificables o verificables. Debe haber una forma de determinar objetivamente si se han cumplido o no. ¿Cómo lo pruebas? “¿El campo ’email’ debe validar el formato de correo electrónico?” es medible; “¿El campo ’email’ debe ser intuitivo?” no lo es.
• Alcanzables (Achievable): Deben ser realistas y posibles de implementar dentro de los recursos y el tiempo del Sprint. Si un criterio es demasiado ambicioso, podría necesitar ser desglosado en historias de usuario más pequeñas.
• Relevantes (Relevant): Deben estar directamente relacionados con la funcionalidad de la historia de usuario y agregar valor al producto. Evita incluir criterios que no contribuyen directamente al objetivo de la historia.
• Con Tiempo (Time-bound – Adaptado): Aunque no se refieren a una fecha límite, implican que la prueba de ese criterio debe ser posible dentro del contexto de la entrega del incremento. Un criterio no puede depender de una funcionalidad que se construirá en un futuro Sprint.

Claridad, no ambigüedad: ejemplos de lo que sí y lo que no

Lo que NO son criterios de aceptación efectivos (ambiguos, no medibles):

• “La interfaz de usuario debe ser atractiva.” (¿Qué es atractivo para quién?)
• “El sistema debe ser rápido.” (¿Qué significa “rápido”? ¿1 segundo, 5 segundos?)
• “Los errores deben manejarse bien.” (¿Qué tipo de manejo? ¿Mensajes, logs, reintentos?)

Lo que SÍ son criterios de aceptación efectivos (específicos, medibles):

• “La paleta de colores de la interfaz de usuario debe coincidir con la guía de estilo corporativa.”
• “La página de inicio debe cargar en menos de 2 segundos con una conexión de 10 Mbps.”
• “Si un campo obligatorio se deja vacío, se debe mostrar un mensaje de error ‘Este campo es requerido’ debajo del campo.”

La clave es que cualquier persona que lea el criterio, ya sea del equipo de desarrollo, de pruebas o el Product Owner, pueda entender exactamente qué se espera y cómo se verificará su cumplimiento.

Ejemplos prácticos de criterios de aceptación para diferentes escenarios

La mejor manera de entender los criterios de aceptación es verlos en acción. Aquí tienes ejemplos basados en los escenarios que describimos previamente, que resaltan cómo los criterios guían la implementación y evitan malentendidos.

Escenario 1: Evitar un problema de expectativas con un nuevo módulo de reporte (Exportación a Excel)

• Historia de Usuario: “Como usuario, quiero poder exportar los reportes de inventario a Excel para su análisis offline.”
• Criterios de Aceptación:
  • Dado que el usuario ha aplicado filtros en el reporte de inventario,
  • Cuando hace clic en el botón “Exportar a Excel”,
  • Entonces se descarga un archivo en formato .xlsx con el nombre “Reporte_Inventario_Fecha.xlsx”.
  • Y el archivo descargado contiene solo las filas visibles en la tabla con los filtros aplicados.
  • Y las primeras 5000 filas del reporte son exportadas si el total supera esa cantidad.
  • Y las cabeceras de las columnas en el Excel coinciden exactamente con las cabeceras de la tabla en la interfaz web.

Escenario 2: Desafío en la definición de una “búsqueda avanzada” en una aplicación de e-commerce

• Historia de Usuario: “Como usuario, quiero poder realizar búsquedas avanzadas por múltiples atributos del producto (marca, color, precio, tamaño) para encontrar rápidamente lo que busco.”
• Criterios de Aceptación (para un atributo específico – Marca):
  • Dado que el usuario está en la página de búsqueda avanzada,
  • Cuando selecciona la marca “Nike” de la lista de filtros,
  • Entonces se muestran solo los productos cuya marca es “Nike”.
  • Y el número de resultados se actualiza para reflejar el conteo de productos Nike.
• Criterios de Aceptación (para un rango de precios):
  • Dado que el usuario ha seleccionado un rango de precios “Entre $50 y $100”,
  • Cuando existen productos en ese rango,
  • Entonces se muestran solo los productos cuyo precio está entre $50 y $100 (inclusive).
  • Y el número de resultados se actualiza.
  • Dado que el usuario ha seleccionado un rango de precios “Entre $50 y $100”,
  • Cuando no existen productos en ese rango,
  • Entonces se muestra el mensaje “No se encontraron productos con los criterios de búsqueda seleccionados”.
  • Y se ofrecen sugerencias de categorías populares debajo del mensaje.
• Criterios de Aceptación (para límite de filtros):
  • Dado que el usuario ha seleccionado 5 filtros (ej. Marca, Color, Talla, Material, Género),
  • Cuando intenta añadir un sexto filtro (ej. Estilo),
  • Entonces la opción para añadir más filtros se deshabilita visualmente.
  • Y se muestra un mensaje informativo “Máximo de 5 filtros aplicables simultáneamente” al intentar la acción.

Estos ejemplos ilustran cómo la definición meticulosa de los criterios de aceptación evita la ambigüedad, guía el desarrollo y las pruebas, y asegura que la funcionalidad entregada cumpla con las expectativas exactas del negocio y del usuario.

Errores comunes al definir criterios de aceptación y cómo evitarlos

A pesar de su importancia, la definición de criterios de aceptación puede caer en trampas comunes que comprometen su efectividad. Reconocerlos es el primer paso para evitarlos.

Demasiado genéricos, demasiado técnicos, incompletos

• Criterios demasiado genéricos: Es el error más común. Un criterio como “El formulario debe funcionar bien” no aporta valor.
  • Cómo evitarlo: Siempre pregunta: “¿Cómo sabremos que esto funciona bien? ¿Qué pasos específicos se deben verificar? ¿Qué resultados esperamos?”. Desglosa la generalidad en pasos medibles.
• Criterios demasiado técnicos: Si bien el equipo de desarrollo colabora, los criterios de aceptación deben ser comprensibles para el Product Owner. Incluir detalles de implementación como “La consulta SQL debe optimizarse con un índice en la tabla X” es un detalle técnico que pertenece a la DoD o a las tareas de desarrollo, no a los criterios de aceptación.
  • Cómo evitarlo: Concéntrate en el “qué” (el comportamiento del sistema desde la perspectiva del usuario o negocio), no en el “cómo” (la implementación técnica).
• Criterios incompletos: Dejar casos de borde o escenarios negativos sin cubrir. Por ejemplo, definir solo el “inicio de sesión exitoso” y no el “inicio de sesión fallido” o el “recuperar contraseña”.
  • Cómo evitarlo: Piensa en todos los caminos posibles: el camino feliz (éxito), los caminos alternativos (otras opciones) y los caminos excepcionales (errores, validaciones). El diálogo continuo entre el Product Owner y el equipo es crucial aquí.

Falta de involucramiento del equipo

Si el Product Owner define los criterios en aislamiento, sin la participación del equipo de desarrollo, pueden surgir problemas:

• Expectativas no realistas: El Product Owner podría definir criterios que son técnicamente complejos o inviables sin saberlo.
• Malentendidos: La interpretación de los criterios puede ser diferente entre el Product Owner y el equipo si no hubo una discusión y consenso.
• Falta de apropiación: El equipo se sentirá menos comprometido con criterios que no ayudaron a definir.
• Cómo evitarlo: Realiza sesiones de refinamiento del Backlog regulares y colaborativas. Fomenta que el equipo haga preguntas, desafíe suposiciones y proponga criterios técnicos que complementen los de negocio. La definición de criterios debe ser un esfuerzo conjunto para asegurar la comprensión y el compromiso.

La importancia de los criterios de aceptación en las pruebas y la entrega

Los criterios de aceptación no son solo una guía para el desarrollo; son la brújula para las pruebas y la validación final del valor entregado.

Guía para el testing: manual y automatizado

Para los equipos de aseguramiento de calidad (QA) o los desarrolladores que realizan pruebas, los criterios de aceptación son oro puro. Se convierten directamente en casos de prueba. Cada criterio de aceptación puede (y debe) transformarse en uno o más escenarios de prueba.

• Pruebas manuales: El probador puede seguir cada criterio como un paso a paso para verificar que la funcionalidad se comporta según lo esperado.
• Pruebas automatizadas: Formatos como Gherkin facilitan enormemente la automatización de pruebas. Las herramientas de BDD (como Cucumber o SpecFlow) permiten ejecutar los escenarios escritos en Gherkin directamente como pruebas automatizadas, creando un puente directo entre los requisitos de negocio y el código de prueba. Esto no solo acelera el proceso de prueba, sino que también asegura que las pruebas cubran lo que realmente importa al negocio.

Esta conexión directa entre criterios de aceptación y pruebas significa que el Product Owner tiene un mecanismo claro para verificar que el trabajo está “Done” y que el equipo tiene una ruta clara para validar su propio trabajo.

Validación con el Product Owner y Stakeholders

Una vez que el equipo de desarrollo considera que una historia de usuario está completa (es decir, cumple con sus criterios de aceptación y con la DoD), el siguiente paso es la validación con el Product Owner. Durante la Revisión del Sprint (Sprint Review), el equipo demuestra la funcionalidad al Product Owner y a otros stakeholders.

Los criterios de aceptación son la lista de verificación que el Product Owner utiliza durante esta demostración. Si todos los criterios se cumplen, el Product Owner puede aceptar la historia de usuario. Si un criterio no se cumple, la historia no está “Done” y el equipo deberá abordarlo en el mismo Sprint (si es posible) o en un Sprint futuro. Esta validación activa y temprana asegura que no haya sorpresas al final del ciclo de desarrollo y que el producto entregado realmente satisfaga las expectativas de negocio.

Conclusión: Los criterios de aceptación como pilar de la calidad en tus proyectos ágiles

En el dinámico mundo de las metodologías ágiles, la ambigüedad es el enemigo de la eficiencia y la calidad. Los criterios de aceptación emergen como una herramienta fundamental para combatirla, sirviendo como un lenguaje compartido y un marco de referencia inequívoco para el Product Owner, el equipo de desarrollo y los stakeholders.

Son mucho más que simples requisitos adicionales; son el tejido conectivo que une la visión del negocio con la ejecución técnica. Al transformar las necesidades generales en condiciones específicas, medibles y verificables, los criterios de aceptación aseguran que cada historia de usuario, cada incremento y, en última instancia, cada entrega de producto, se alinee perfectamente con lo que el usuario y el negocio realmente necesitan.

La inversión de tiempo y esfuerzo en definir criterios de aceptación claros y detallados durante el refinamiento del Backlog se traduce directamente en:

• Menos retrabajo: Se evitan malentendidos y suposiciones incorrectas.
• Mayor eficiencia: El equipo sabe exactamente qué construir y las pruebas son más directas.
• Mejor calidad del producto: Las funcionalidades entregadas cumplen con las expectativas y son probables.
• Confianza y transparencia: Todos los involucrados tienen una comprensión compartida del progreso y el “Done”.

Quienes trabajamos en agilidad sabemos que la calidad no es un accidente, sino el resultado de un esfuerzo intencional y una comunicación impecable. Implementar y dominar el arte de los criterios de aceptación es un paso crucial hacia un “Done” claro, predecible y, sobre todo, valioso en cada Sprint.