Cómo escribir historias de usuario (con ejemplos y criterios de aceptación)
Una historia de usuario es una descripción breve de una funcionalidad desde el punto de vista del usuario: «Como [tipo de usuario], quiero [objetivo] para que [motivo]». Debajo escribes los criterios de aceptación, unas pocas condiciones concretas que deben cumplirse para que la historia se considere terminada. Mantén cada historia lo bastante pequeña como para construirla y probarla de una vez, y redacta los criterios de forma que cualquiera pueda comprobarlos.
Las historias de usuario se popularizaron en los equipos de software ágiles, pero son igual de útiles cuando construyes por tu cuenta con un generador de apps con IA. Una buena historia es un buen prompt.
El formato
Una historia de usuario tiene tres partes:
Como [quién], quiero [qué] para que [por qué].
- Quién es un tipo concreto de usuario: un visitante que llega por primera vez, un socio que paga, un recepcionista de una clínica, un administrador. No «el usuario».
- Qué es lo que quiere hacer, con sus propias palabras. No cómo funciona la pantalla.
- Por qué es el resultado que le importa. Es la parte que la gente se salta, y la que evita que construyas lo equivocado.
Ejemplo:
Como socio del gimnasio, quiero cancelar una reserva de clase desde mi móvil para que alguien de la lista de espera pueda ocupar mi plaza y no me cobren una penalización por no presentarme.
El «por qué» te dice dos cosas que el «qué» no decía: tiene que funcionar en el móvil, y están implicadas la lista de espera y las normas de la penalización.
Criterios de aceptación
La historia dice lo que se quiere. Los criterios de aceptación dicen cuándo está hecho. Deben ser lo bastante concretos como para que dos personas se pongan de acuerdo sobre si cada uno se cumple.
Una forma habitual de escribirlos es Dado / Cuando / Entonces:
- Dado una situación inicial
- Cuando el usuario hace algo
- Entonces este es el resultado
Para la historia de la reserva del gimnasio:
- Dado que tengo una reserva a más de 12 horas, cuando pulso Cancelar y confirmo, entonces la reserva se elimina y veo «Reserva cancelada».
- Dado que cancelo una reserva y la clase tiene lista de espera, cuando se guarda la cancelación, entonces la primera persona de la lista de espera recibe la plaza y un correo.
- Dado que tengo una reserva a menos de 12 horas, cuando pulso Cancelar, entonces veo que se aplica una penalización por cancelación tardía antes de confirmar.
- Dado que estoy en una pantalla del ancho de un móvil, entonces el botón Cancelar es visible sin desplazarme lateralmente.
Una lista de comprobación sencilla también funciona, siempre que cada punto sea comprobable. «Cancelar es fácil» no es comprobable. «Cancelar requiere como máximo dos toques desde la lista de reservas» sí lo es.
Paso a paso: cómo escribir una buena historia
Paso 1: parte de un usuario real y un problema real
Elige un tipo de usuario y algo con lo que tenga dificultades hoy. Si has hecho entrevistas con clientes, usa sus palabras. «Siempre me olvido de cancelar y me cobran» es mejor punto de partida que «añadir funcionalidad de cancelación».
Paso 2: escribe la historia en una línea
Rellena la plantilla. Si no consigues escribir un «para que» convincente, pregúntate si la funcionalidad hace falta de verdad.
Paso 3: añade de tres a seis criterios de aceptación
Cubre primero el caso de éxito principal y después las variaciones importantes: otro rol, un estado vacío, un límite, un error. Si escribes más de seis, la historia probablemente es demasiado grande.
Paso 4: anota qué queda fuera del alcance
Una línea te ahorra mucho ir y venir: «Fuera de alcance: reembolsos de clases de pago; administradores que cancelan en nombre de los socios». Evita que la historia crezca mientras construyes.
Paso 5: compruébala con INVEST
INVEST es una lista de comprobación habitual para historias bien hechas. Una historia debe ser:
| Letra | Significa | Prueba rápida |
|---|---|---|
| I | Independiente | Se puede construir sin esperar a otra historia |
| N | Negociable | Describe la necesidad, no un diseño cerrado |
| V | Valiosa | Un usuario lo notaría si se publicara |
| E | Estimable | Puedes adivinar más o menos su tamaño |
| S | Pequeña | Se construye y se prueba en una sola sesión |
| T | Comprobable | Cada criterio de aceptación se puede verificar |
No hace falta puntuar cada historia. Es más útil cuando una historia no te convence y quieres saber por qué.
Ejemplos buenos y malos
| Historia débil | Problema | Historia mejor |
|---|---|---|
| Como usuario, quiero un panel. | Sin usuario concreto, sin motivo, no comprobable | Como dueña de una tienda, quiero ver los pedidos y los ingresos de hoy en una sola pantalla para saber de un vistazo si el día va bien. |
| Como administrador, quiero que la base de datos tenga una columna de estado. | Describe la implementación, no una necesidad | Como administrador, quiero marcar los pedidos como enviados para que los clientes dejen de escribir para preguntar dónde están. |
| Como cliente, quiero gestionar mi cuenta. | Demasiado grande: abarca muchas funcionalidades | Como cliente, quiero cambiar mi dirección de correo para que los recibos lleguen a mi nueva bandeja de entrada. |
| Como visitante, quiero que la web sea rápida. | No es una historia, es una cualidad que todas necesitan | Escríbelo como criterio en cada historia, o como objetivo de rendimiento aparte. |
Cómo dividir una historia demasiado grande
Las historias grandes son donde los proyectos se atascan. Formas habituales de dividirlas:
- Por rol de usuario. Los socios cancelan sus propias reservas; el personal cancela las de cualquiera.
- Por paso del flujo. Explorar clases; reservar una clase; recibir un recordatorio.
- Caso sencillo primero. Cancelar una clase gratuita ahora; gestionar penalizaciones y reembolsos en una historia posterior.
- Por variación de datos. Admitir primero una sola sede; varias después.
- Camino feliz y luego errores. Construirlo funcionando y después añadir el tratamiento de clases completas, abonos caducados, etc.
Cada parte debe seguir siendo algo que un usuario pueda usar y notar.
Usar historias de usuario como prompts
Una historia de usuario con criterios de aceptación está muy cerca de un buen prompt para un generador de apps con IA. Le da a la IA el quién, el qué, el por qué y una definición de terminado. Envía una historia por mensaje:
Como socio del gimnasio, quiero cancelar una reserva de clase desde mi móvil para que alguien de la lista de espera pueda ocupar mi plaza. Criterios de aceptación:
- Cancelar aparece en cada reserva de Mis reservas, con un paso de confirmación.
- Cancelar con más de 12 horas de antelación solo elimina la reserva.
- Con menos de 12 horas, muestra «Se aplica una penalización de 5 $ por cancelación tardía» antes de confirmar, y registra la penalización en la reserva.
- Si la clase tiene lista de espera, la primera persona recibe la plaza y un correo.
- Funciona en una pantalla del ancho de un móvil. Fuera de alcance: reembolsos y cancelaciones hechas por el personal en nombre de los socios. Construye esto y luego comprueba cada criterio en la vista previa y dime cuáles se cumplen.
También puedes pedir a la IA que redacte historias a partir de una idea aproximada y luego editarlas tú:
Esta es la idea de mi app: [dos o tres frases]. Escribe las historias de usuario para una primera versión, agrupadas por tipo de usuario, cada una con de 3 a 5 criterios de aceptación Dado/Cuando/Entonces. Marca cuáles son imprescindibles para el lanzamiento y cuáles pueden esperar.
Lee y edita siempre el resultado. La IA no conoce a tus usuarios; tú sí.
Los criterios de aceptación también sirven como plan de pruebas. Cuando la historia esté construida, recorre tú mismo cada criterio. Nuestra guía sobre cómo probar tu app antes del lanzamiento se basa en esto.
Dónde encajan las historias de usuario con otros documentos
- Un documento de requisitos de producto describe el producto completo: el problema, los usuarios, el alcance. Las historias de usuario son las piezas detalladas que contiene. Consulta cómo escribir un PRD con IA.
- Un informe de error describe algo que está roto frente a una historia que ya se construyó. Consulta cómo escribir un buen informe de error.
- Un MVP es el conjunto más pequeño de historias que ofrece el valor principal. Consulta qué es un MVP.
Errores habituales
- «Como usuario…». Demasiado vago. Nombra el tipo concreto de usuario.
- Omitir el «para que». Sin el motivo, no puedes tomar decisiones de compromiso razonables.
- Escribir la solución en lugar de la necesidad. «Quiero un desplegable» fija un diseño antes de que nadie lo haya pensado.
- Criterios que no se pueden probar. «Fácil», «rápido» e «intuitivo» son deseos, no criterios.
- Historias que en realidad son épicas. «Gestionar mi cuenta» son diez historias.
- Escribir todas las historias por adelantado. Escribe en detalle las siguientes dos o tres; deja el resto como una línea hasta que llegues a ellas.
Historias en Mythex
En Mythex, el modo Plan es un buen lugar para convertir una idea en historias: el agente comenta el enfoque antes de editar nada. Cuando una historia esté lista, cambia a Build y pégala, una historia por mensaje. Después de cada una, /test puede hacer clic en la vista previa y comprobar el flujo, y puedes revertir cualquier respuesta con Revert to this point si ha salido mal. Consulta prompts eficaces en la documentación, y nuestra guía sobre cómo escribir prompts para generadores de apps con IA.
Lista de comprobación de historias de usuario
- Nombra un tipo concreto de usuario
- Describe una necesidad, no un diseño
- Incluye un «para que» real
- Tiene de tres a seis criterios de aceptación comprobables
- Cubre al menos un caso límite o error
- Indica qué queda fuera del alcance
- Es lo bastante pequeña para construirla y probarla de una vez
- Los criterios se comprueban uno a uno después de construirla
Preguntas
¿Cuál es el formato de una historia de usuario?
La plantilla habitual es: Como [tipo de usuario], quiero [objetivo] para que [motivo]. A continuación van los criterios de aceptación, una lista breve de condiciones que deben cumplirse para que la historia se considere terminada.
¿Qué son los criterios de aceptación?
Los criterios de aceptación son condiciones concretas y comprobables que definen cuándo está completa una historia de usuario. A menudo se escriben como Dado / Cuando / Entonces: dada una situación inicial, cuando el usuario hace algo, entonces ocurre un resultado concreto.
¿Qué tamaño debe tener una historia de usuario?
Lo bastante pequeña para construirla y probarla de una vez, pero que siga aportando valor por sí sola. Si una historia tiene más de cinco o seis criterios de aceptación o abarca varias pantallas, divídela por rol de usuario, por paso del flujo o por caso sencillo primero y casos límite después.
¿Son útiles las historias de usuario cuando se construye con IA?
Sí. Una historia de usuario con criterios de aceptación se acerca a un prompt ideal: indica para quién es la funcionalidad, qué necesita y exactamente cómo comprobar que funciona. Enviar una historia por mensaje también mantiene los cambios de la IA pequeños y fáciles de probar.