Escribe buenos criterios de aceptación para historias de usuario

En este artículo aprenderás a escribir historias de usuario claras y útiles, centrándonos en cómo definir buenos criterios de aceptación. Todo basado en ejemplos concretos.

⏱️ Tiempo de lectura: 4 minutos.

1. Historias de usuario: más que una plantilla

Una historia de usuario no es solo un formato “Como [usuario] quiero [funcionalidad] para [beneficio]”, sino una herramienta para conectar la necesidad del usuario con el trabajo del equipo de producto.

Su origen está en la idea de:

• Superar el modelo de especificaciones cerradas.

• Fomentar la conversación y la colaboración.

• Generar foco en el valor real que se quiere conseguir.

📌 Para esto, se usan las 3 Cs de las historias de usuario:

• Card (tarjeta): La historia se describe de forma breve y sencilla.

• Conversation (conversación): Se aclaran dudas, se exploran soluciones y se negocian enfoques.

• Confirmation (confirmación): Se definen los criterios de aceptación que validan cuándo está “hecho”.

✅ El formato sirve como punto de partida, pero lo importante es el ciclo de vida de cada historia y cómo evoluciona hasta estar lista para desarrollarse.

Ejemplo (GymApp):

Como cliente, quiero ver las clases disponibles en el calendario, para poder reservar la que más me convenga.

Esta historia se escribirá con esta frase simple en su Card, se conversará con diseño y desarrollo sobre cómo mostrar las clases y se confirmará con criterios de aceptación.

👉 VISITA MI NEWSLETTER SEMANAL PARA MÁS CONTENIDO

2. Cómo escribir buenos criterios de aceptación (y qué estilo usar)

Los criterios de aceptación definen cuándo se puede considerar que una funcionalidad cubre las necesidades del usuario, validando el entendimiento compartido entre negocio, diseño, desarrollo y testing.

¿Es lo mismo el criterio de aceptación y la Definición de Hecho del producto? No. En este artículo explico las diferencias entre ambas.

¿Hay que escribir los criterios siempre en formato Gherkin? No. Existen dos estilos válidos, y cada uno tiene su momento.
 

🟦 Estilo narrativo simple (fácil y directo)

Este formato se usa con frases sencillas. Es ideal durante las fases tempranas de una historia (Card o Conversation), cuando aún estamos explorando la funcionalidad.

Ejemplo (reserva de clases en GymApp):

• “El usuario puede ver todas las clases con plazas libres.”
• “Si intenta reservar una clase llena, recibe un aviso.”
• “Tras reservar, ve un mensaje de confirmación.”

Este estilo mantiene la conversación abierta sin invertir demasiado en detalles prematuros.
 

🟨 Estilo Gherkin (más estructurado y formal)

Cuando una historia se acerca a entrar en un sprint, o si la funcionalidad tiene riesgo técnico o funcional, se puede usar Gherkin:

# Historia: Reserva de clases desde el calendario
Escenario: Mostrar solo clases con plazas disponibles

Dado que el usuario ha iniciado sesión en GymApp

Cuando accede al caºlendario de clases

Entonces solo ve las clases que tienen plazas disponibles

 

Escenario: Aviso si se intenta reservar clase sin plazas

Dado que el usuario ha iniciado sesión y consulta una clase sin plazas

Cuando pulsa el botón de reserva

Entonces se muestra un mensaje indicando que la clase está completa

 

Este estilo es útil para:

• Asegurar consistencia.
• Facilitar automatización.
• Alinear a equipos técnicos y de negocio.

¿Cómo elegir?

👉 Lo recomendable es comenzar con el estilo narrativo simple para explorar y refinar, y evolucionar hacia Gherkin cuando la historia esté lista para su desarrollo y sea necesario validar el comportamiento con más precisión.

📌 Lo importante no es tanto el formato, sino que:

• Los criterios sean entendibles por todos.
• Sirvan para validar el valor entregado.
• Ayuden a construir confianza en el equipo.

4. Errores comunes al definir criterios de aceptación (y cómo evitarlos)

Incluso cuando una historia está bien planteada, los criterios de aceptación pueden generar confusión si no se definen adecuadamente. Aquí te comparto algunos errores frecuentes que deberías evitar, junto con recomendaciones prácticas para corregirlos: 🔸 Criterios demasiado vagos o generales

❌ “Debe funcionar correctamente” o “El usuario estará satisfecho”. ✅ Usa condiciones observables y medibles, como: “El usuario recibe un mensaje de confirmación en menos de 3 segundos”.

🔸 Criterios que duplican lo que ya dice la historia

❌ Repetir el texto de la historia en los criterios no añade valor. ✅ Aporta condiciones específicas que validen qué significa que “la funcionalidad está lista para usarse”.

🔸 Criterios escritos solo desde el punto de vista técnico

❌ “El campo se guarda en la base de datos con una clave única.” ✅ “El usuario puede recuperar su clase reservada desde el calendario personal.” 🔁 Alinea los criterios con la experiencia del usuario, no solo con la implementación.

🔸 Demasiado enfoque en detalles de UI prematuros

❌ “El botón debe ser azul y tener sombra.” ✅ Concéntrate en el comportamiento esperado, y deja que diseño y desarrollo concreten los detalles.

📌 Un buen truco es revisar los criterios en equipo antes del sprint. ¿Todos los entienden igual? ¿Hay casos límite no contemplados? ¿Podríamos automatizar estos criterios? Recuerda: los criterios de aceptación son una herramienta para facilitar la colaboración y evitar sorpresas durante el desarrollo. Cuanto más claro y compartido sea lo que significa “hecho”, más fluido será el trabajo en el equipo.

5. Cómo revisar los criterios en equipo

Validar los criterios de aceptación como parte del proceso de refinamiento es una práctica clave. No se trata solo de escribirlos, sino de asegurar que todo el equipo los entiende, los valida y los asume como referencia común. 📌 Puedes aprovechar las sesiones de refinamiento o planificación para:

• Leer en voz alta cada criterio.
• Preguntar si hay ambigüedad o dudas.
• Acordar cómo se validará (test manual, automatización, demo…).

En GymApp, por ejemplo, el equipo revisa los criterios para la historia de reserva de clases y añade uno más tras detectar un caso no contemplado:

“Si el usuario intenta reservar dos clases que se solapan, se le muestra un aviso.”

Este tipo de revisión colaborativa reduce errores y malentendidos durante el desarrollo.

6. Qué rol tiene cada persona

El trabajo con historias de usuario y criterios de aceptación es colaborativo, pero cada perfil tiene un rol diferente:

• Product Owner: Define el valor, prioriza las historias y propone los criterios iniciales.
• Desarrolladores: Ayudan a detectar casos límite, validan la viabilidad y escriben pruebas.
• Diseñadores UX: Aportan el punto de vista de la experiencia del usuario.
• Testers / QA: Proponen casos y validaciones, automatizan criterios cuando aplica.

📌 Cuanto antes se involucren todos, más clara y consensuada será la historia.

7. Conclusión

Escribir buenas historias de usuario no es cuestión de seguir una plantilla, sino de fomentar una colaboración efectiva entre los roles del equipo, centrados en entregar valor real al usuario. Los criterios de aceptación son el nexo entre la conversación y la validación. 

Y como has visto, hay distintos estilos para expresarlos, dependiendo del momento y del riesgo. Si combinas claridad, participación y revisión frecuente, estarás más cerca de tener historias bien definidas y equipos mejor alineados. 🧭 

¿El siguiente paso? Revisa tus próximas historias en equipo y valida si los criterios cumplen con todo lo que hemos comentado aquí. ¡Y si quieres mejorar más, puedes leer también nuestra guía de refinamiento!

🔗 Artículos relacionados en ITNOVE

• Definición de Hecho y criterios de aceptación: diferencias y buen uso → Para entender cómo se complementan ambos elementos.
• Guía definitiva para el refinamiento en Scrum → Aprende a preparar historias de usuario para que estén listas para el sprint.
• 7 hábitos de Product Owners altamente efectivos → Buenas prácticas que te ayudarán a mejorar la gestión del backlog.
• Simulador gratuito de examen PSPO I → Practica tus conocimientos sobre Product Ownership.