Cómo escribir historias de usuario (con ejemplos y criterios de aceptación)
Una historia de usuario es una descripción breve de una función 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 para construirla y probarla de una vez, y escribe 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 creador 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, una recepcionista de clínica, un administrador. No “el usuario”.
- Qué es lo que quiere hacer, con sus 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 construir 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 tarifa 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 reglas de la tarifa.
Criterios de aceptación
Una historia dice lo que se quiere. Los criterios de aceptación dicen cuándo está terminada. Deben ser lo bastante concretos como para que dos personas coincidan en 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 toco 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 una reserva es a menos de 12 horas, cuando toco Cancelar, entonces veo que se aplica una tarifa 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 se ve sin desplazarme de lado.
Una lista simple de comprobación también sirve, siempre que cada elemento 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: 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 se me olvida cancelar y me cobran” es un mejor punto de partida que “añadir función de cancelación”.
Paso 2: escribe la historia en una línea
Rellena la plantilla. Si no puedes escribir un “para que” convincente, pregúntate si la función hace falta de verdad.
Paso 3: añade entre tres y 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, probablemente la historia es demasiado grande.
Paso 4: anota qué queda fuera
Una línea ahorra mucha ida y vuelta: “Fuera de alcance: reembolsos de clases de pago; administradores que cancelan en nombre de los socios.” Evita que la historia crezca mientras la construyes.
Paso 5: compruébala con INVEST
INVEST es una lista de comprobación habitual para buenas historias. 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 calcular más o menos su tamaño |
| S | Pequeña | Se construye y prueba en una sola sesión |
| T | Comprobable | Cada criterio de aceptación puede verificarse |
No necesitas 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 escribirme para preguntar dónde está su pedido. |
| Como cliente, quiero gestionar mi cuenta. | Demasiado grande: cubre muchas funciones | 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 todos 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 estancan. Formas habituales de dividirlas:
- Por rol de usuario. Los socios cancelan sus propias reservas; el personal cancela cualquiera.
- Por paso del flujo. Explorar clases; reservar una clase; recibir un recordatorio.
- Caso sencillo primero. Cancelar una clase gratuita ahora; tratar tarifas y reembolsos en una historia posterior.
- Por variación de datos. Admitir una sede primero; varias más adelante.
- Camino feliz, después errores. Construirla funcionando y luego añadir el tratamiento de clases llenas, pases caducados, etc.
Cada pieza 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 es muy parecida a un buen prompt para un creador de apps con IA. Le da a la IA el quién, el qué, el porqué 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 más de 12 horas antes de la clase simplemente elimina la reserva.
- Con menos de 12 horas, muestra “Se aplica una tarifa de cancelación tardía de 5 $” antes de confirmar, y registra la tarifa 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, cancelaciones hechas por el personal en nombre de los socios. Construye esto y, después, comprueba cada criterio en la vista previa e indícame cuáles se cumplen.
También puedes pedir a la IA que redacte historias a partir de una idea aproximada, y editarlas tú:
Esta es mi idea de app: [dos o tres frases]. Escribe las historias de usuario para una primera versión, agrupadas por tipo de usuario, cada una con 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 apoya 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 roto frente a una historia que ya estaba construida. Consulta cómo escribir un buen informe de error.
- Un MVP es el conjunto más pequeño de historias que entrega el valor principal. Consulta qué es un MVP.
Errores comunes
- “Como usuario…” Demasiado vago. Nombra el tipo concreto de usuario.
- Omitir el “para que”. Sin el motivo, no puedes tomar decisiones sensatas de compromiso.
- Escribir la solución en lugar de la necesidad. “Quiero un desplegable” fija un diseño antes de que nadie haya pensado en él.
- 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 próximas tres o cuatro; 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 habla del enfoque antes de editar nada. Cuando una historia esté lista, cambia a Build y pégala, una historia por mensaje. Tras cada una, /test puede hacer clic por la vista previa y comprobar el flujo, y puedes deshacer cualquier respuesta con Revert to this point si salió mal. Consulta prompts efectivos en la documentación y nuestra guía sobre cómo escribir prompts para creadores 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 motivo real con “para que”
- Tiene entre tres y seis criterios de aceptación comprobables
- Cubre al menos un caso límite o error
- Indica qué queda fuera de alcance
- Es lo bastante pequeña para construirla y probarla de una vez
- Criterios comprobados tras construir, uno a uno
Preguntas
¿Cuál es el formato de una historia de usuario?
La plantilla habitual es: Como [tipo de usuario], quiero [objetivo] para que [motivo]. Le sigue una lista de criterios de aceptación: condiciones breves que deben cumplirse para que la historia se considere terminada.
¿Qué son los criterios de aceptación?
Son condiciones concretas y comprobables que definen cuándo una historia de usuario está completa. 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, y que aun así tenga 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 los casos límite después.
¿Son útiles las historias de usuario al construir con IA?
Sí. Una historia de usuario con criterios de aceptación se acerca a un prompt ideal: dice para quién es la función, 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.