Historias de usuario: qué son, ejemplos y plantilla
Las historias de usuario son la forma más usada de describir lo que un producto debe hacer, contado desde el punto de vista de quien lo usa. En lugar de una lista fría de requisitos, una historia explica quién necesita algo, qué necesita y para qué. Esa pequeña diferencia cambia cómo trabaja un equipo.
En esta guía verás qué son, el formato estándar, cómo escribirlas bien, ejemplos por contexto, los criterios de aceptación y la prueba INVEST. Y abajo tienes un constructor gratis: rellenas tres campos, arma la historia y sus criterios, y los copias listos para tu herramienta.
Qué es una historia de usuario
Definición
Una historia de usuario es una descripción breve de una funcionalidad, escrita desde la perspectiva de la persona que la va a usar.
Su origen está en el desarrollo ágil, dentro de marcos como Scrum y Kanban. La idea es sencilla: en vez de redactar un documento de requisitos extenso, el equipo captura cada necesidad en una frase corta que invita a conversar. La historia no pretende cerrar todos los detalles, sino abrir la charla que los define.
Por eso una historia de usuario no es una especificación técnica. Es un recordatorio de una conversación pendiente entre el equipo y quien usará el producto. Su valor está en mantener el foco en la persona y en el problema, no en la solución.
Constructor de historias de usuario
Rellena los tres campos. El constructor arma la frase, agrega los criterios de aceptación en el formato que elijas y apila las historias para que las copies a tu herramienta.
Criterios de aceptación
El formato: Como, quiero, para
Casi todas las historias siguen una misma plantilla de tres partes, fácil de recordar y de completar:
Como [perfil], quiero [objetivo], para [resultado].
Como [perfil]. Quién tiene la necesidad. Conviene ser específico: un comprador que regresa no es lo mismo que uno nuevo.
Quiero [objetivo]. Qué quiere lograr, en lenguaje de negocio. Describe la meta, no la solución técnica.
Para [resultado]. El porqué. Es la parte que más se olvida y la que le da sentido a todo lo demás.
Cómo escribir una buena historia de usuario
La plantilla es solo el molde. Una buena historia se construye con estos cuatro pasos, que el constructor de arriba sigue de forma natural.
- Define el perfil (Como) Empieza por quién. No escribas "el usuario" a secas: sé concreto. Un gerente de cuentas, un comprador que regresa o un editor de contenido tienen necesidades distintas, y el perfil correcto orienta todo lo demás.
- Describe la necesidad (Quiero) Di qué quiere lograr ese perfil, en lenguaje de negocio, no técnico. Habla de la meta del usuario, no de la solución. "Quiero ver primero mis cuentas en riesgo", no "quiero un filtro con un dropdown".
- Explica el propósito (Para) Cierra con el porqué. Esta parte es la que más se salta y la más valiosa: si el equipo entiende para qué sirve, puede proponer una mejor solución que la que tenías en mente.
- Agrega los criterios de aceptación Define cómo sabrás que la historia está terminada. Sin esto, "hecho" significa algo distinto para cada persona y la historia vuelve una y otra vez.
Las 3 Cs de las historias de usuario
Ron Jeffries resumió la esencia de una historia en tres palabras que empiezan con C. Sirven para recordar que una historia es mucho más que la frase escrita en la tarjeta.
| Las 3 Cs | Qué significa |
|---|---|
| Card (tarjeta) | La frase corta que describe la historia. Es solo el recordatorio, no el detalle completo. |
| Conversation (conversación) | La charla entre el equipo y el dueño del producto que aclara dudas y explora soluciones. |
| Confirmation (confirmación) | Los criterios de aceptación que definen cuándo la historia está realmente terminada. |
Ejemplos de historias de usuario
La mejor forma de entender el formato es verlo aplicado. Estos ejemplos muestran historias reales en distintos contextos, cada una con un criterio de aceptación para aterrizarla.
Fíjate en el patrón: ninguna menciona botones, pantallas ni tecnología. Todas hablan de una persona, una meta y un porqué. El cómo se decide después, en la conversación.
Criterios de aceptación
Los criterios de aceptación son las condiciones que una historia debe cumplir para considerarse terminada. Son la C de confirmación, y sin ellos la palabra "hecho" significa algo distinto para cada persona del equipo.
Hay dos formas habituales de escribirlos. La más simple es una lista de condiciones verificables. La más usada en equipos ágiles es el formato Gherkin, que describe un escenario con tres partes:
Dado que el usuario tiene artículos en el carrito, cuando hace clic en Pagar, entonces ve el resumen del pedido antes de confirmar.
El valor del formato Dado, cuando, entonces es que obliga a pensar en el contexto, la acción y el resultado esperado. El constructor de arriba te deja escribir los criterios en cualquiera de los dos formatos y copiarlos junto con la historia.
La forma de lista simple funciona mejor para condiciones sueltas que no dependen de un escenario. Para la misma historia del carrito, podría verse así: el resumen muestra el total con impuestos, permite editar las cantidades y avisa si un artículo se quedó sin stock. Cada línea es una condición que se puede comprobar con un sí o un no.
Un buen criterio es concreto y verificable. Si no puedes imaginar una prueba que lo confirme, todavía está demasiado vago. Y conviene escribirlos antes de empezar a desarrollar, no después: son parte de la conversación que define la historia, no un trámite final.
INVEST: cómo saber si está bien escrita
INVEST es una regla nemotécnica creada por Bill Wake para revisar la calidad de una historia. No es una nota que se calcula, sino seis preguntas que conviene hacerse antes de dar una historia por lista.
| Criterio | Qué revisa |
|---|---|
| Independiente | Se puede desarrollar sin depender de otras historias. |
| Negociable | Deja espacio para discutir el cómo; no es un contrato cerrado. |
| Valiosa | Aporta un valor claro a quien usa el producto. |
| Estimable | El equipo puede estimar cuánto cuesta hacerla. |
| Pequeña | Cabe dentro de un sprint; si no, es una épica. |
| Comprobable | Tiene criterios de aceptación que permiten probar si está hecha. |
Si una historia falla en varias de estas preguntas, no significa que esté mal: significa que conviene conversarla o dividirla antes de llevarla al sprint.
Historias, épicas y tareas
Las historias de usuario viven dentro de una jerarquía. Saber en qué nivel estás evita escribir historias demasiado grandes o demasiado pequeñas.
| Nivel | Qué es | Ejemplo |
|---|---|---|
| Épica | Un objetivo grande que no cabe en un sprint | Rediseñar el proceso de pago |
| Historia de usuario | Una necesidad concreta que sí cabe en un sprint | Guardar la tarjeta para próximas compras |
| Tarea | El trabajo técnico para completar la historia | Crear el endpoint para guardar la tarjeta |
Cuando una épica se divide en historias y se ordena por el recorrido del usuario, el resultado es un mapa de historias de usuario. Es una vista útil para planear entregas, porque muestra qué historias forman juntas una experiencia completa. Si trabajas con iteraciones, ayuda enlazarlo con tus metodologías de gestión de proyectos.
Cómo dividir una épica en historias
Dividir bien una épica es una de las habilidades que más cuesta y más rinde. El error típico es partirla por capas técnicas (una historia para la base de datos, otra para la interfaz), porque ninguna de esas partes entrega valor por sí sola. La regla es que cada historia, por pequeña que sea, debe poder demostrarse a un usuario.
Por pasos del flujo. Si la épica es un proceso, una historia por cada paso: buscar, agregar al carrito, pagar, confirmar.
Por reglas de negocio. Separa el caso simple del complejo: primero pagar con tarjeta, luego pagar con cupón, luego pagar en cuotas.
Por tipo de dato o variante. Una historia para el caso más común y otras para las variantes: subir una foto, después varias, después un video.
Una buena señal de que la división funciona es que puedes ordenar las historias por valor y entregar las primeras sin esperar al resto. Si una historia no se puede soltar sin las demás, todavía está demasiado pegada.
Errores comunes al escribir historias de usuario
Estos tropiezos aparecen una y otra vez, y son fáciles de evitar una vez que los reconoces.
- Escribir la solución en lugar de la necesidad "Quiero un botón azul arriba a la derecha" no es una historia, es una orden de trabajo. Describe qué necesita lograr el usuario y deja que el equipo proponga el cómo.
- Saltarse el "para" Sin el propósito, la historia pierde su parte más útil. El porqué es lo que permite al equipo encontrar una mejor solución y decidir bien cuando hay que recortar.
- Historias gigantes que no caben en un sprint Si una historia parece un proyecto entero, es una épica disfrazada. Divídela en historias más pequeñas que se puedan terminar y probar por separado.
- Dejarla sin criterios de aceptación Sin una definición clara de "hecho", cada quien interpreta distinto y la historia rebota entre desarrollo y revisión. Los criterios cierran esa puerta.
Preguntas frecuentes
La historia describe una necesidad desde el punto de vista del usuario y aporta valor por sí sola. La tarea es el trabajo técnico para construir esa historia, y casi nunca tiene sentido para el usuario por separado. Una historia suele desglosarse en varias tareas.
No hay un número fijo: depende del tamaño de las historias y de la capacidad del equipo. En vez de contar historias, los equipos estiman el esfuerzo de cada una y toman las que caben en su capacidad del sprint. Si una historia no cabe, probablemente es una épica y conviene dividirla.
Suele hacerlo el dueño del producto, pero la historia mejora cuando participa todo el equipo. Escribir entre varios saca a la luz dudas y supuestos que una sola persona no vería. Recuerda que la historia es el inicio de una conversación, no un documento cerrado.
Una épica es un objetivo grande que no cabe en un solo sprint y que se divide en varias historias de usuario. Por ejemplo, rediseñar todo el proceso de pago es una épica; guardar la tarjeta para próximas compras es una de sus historias.
Lo que hacemos en Rock
En Rock trabajamos con equipos que escriben historias todo el tiempo, y vemos un patrón claro. La historia se redacta bien, pero después vive en una herramienta y la conversación que la define ocurre en otra. Cuando llega el momento de construirla, la mitad del contexto se perdió en el camino.
Por eso construimos Rock alrededor de un solo espacio donde el chat, las tareas y las notas conviven. Una historia puede nacer como mensaje, convertirse en una tarea con responsable y criterios, y mantener al lado la conversación que la aclara. Nada se reparte entre cinco apps.
De la historia a la tarea, sin cambiar de app
Convierte cada historia en una tarea con responsable y criterios, junto al chat donde el equipo la conversa. Un solo espacio, precio plano, usuarios ilimitados.
Nuestra recomendación es directa: escribe la historia con su formato y sus criterios, pero llévala a un lugar donde la conversación y el trabajo no se separen. Para decidir qué historias atacar primero, una guía para priorizar tareas te da varios métodos. Y si quieres ubicar el tema dentro de Scrum, empieza por qué es Scrum.
Una historia de usuario solo cobra valor cuando el equipo la convierte en trabajo. Rock combina chat, tareas y notas en un solo espacio. Un precio plano, usuarios ilimitados. Empieza gratis.
