1. Blog de Pulsión Digital
2. Empresas

• Actualizado: octubre 23, 2026

Cómo escribir historias de usuario: plantilla, ejemplos y criterios

Saber cómo escribir historias de usuario es una de las habilidades más útiles para cualquiera que trabaje en producto: product managers, diseñadores, desarrolladores y hasta fundadores que hablan con su primer equipo técnico. Una buena historia de usuario cabe en una tarjeta, pero resume quién necesita algo, qué necesita y, sobre todo, para qué lo necesita 🧩

En esta guía vas a ver la plantilla explicada desde la parte que más se descuida (el «para»), ejemplos buenos y malos, cómo escribir criterios de aceptación, cómo dividir historias grandes, de dónde viene el formato y cómo usar la IA como revisor sin delegarle las decisiones. Al final tienes un ejercicio para practicar con tu propio backlog.

¿Quieres aprender a decidir qué construir y por qué, con la IA como copiloto?

Qué es una historia de usuario

Una historia de usuario (user story en inglés) es una descripción breve de una funcionalidad, escrita desde la perspectiva de la persona que la va a usar. No es una especificación técnica ni un documento de requisitos: es un recordatorio de una conversación que el equipo necesita tener.

Esa idea viene de los orígenes del concepto. En 2001, Ron Jeffries, uno de los creadores de la Programación Extrema (XP), describió las historias con tres «C»:

• Card (tarjeta): la historia se escribe en una tarjeta que no contiene toda la información del requisito; sirve para identificarlo y recordarlo en la planificación.
• Conversation (conversación): los detalles surgen del diálogo entre quien pide la funcionalidad y quien la construye.
• Confirmation (confirmación): las pruebas de aceptación confirman que la historia está terminada.

Esto explica el error más frecuente de los equipos nuevos: creer que la historia debe contenerlo todo. La tarjeta es corta a propósito; lo que la hace funcionar es la conversación que provoca y los criterios que la cierran.

Historias, épicas y tareas: no son lo mismo

Nivel	Qué es	Tamaño típico	Ejemplo
Épica	Un objetivo grande que agrupa varias historias	Varias iteraciones	Pagos dentro de la app
Historia de usuario	Una necesidad concreta que entrega valor por sí sola	Cabe en una iteración	Como cliente frecuente, quiero guardar mi tarjeta para pagar más rápido la próxima vez
Tarea	Un paso técnico para construir la historia	Horas o un par de días	Crear el endpoint para guardar tarjetas tokenizadas

La diferencia clave: una historia entrega valor a alguien; una tarea, por sí sola, no. «Crear la tabla de la base de datos» no es una historia, porque ningún usuario gana nada hasta que la funcionalidad completa existe.

La plantilla «Como… quiero… para…», explicada desde el «para»

La plantilla más usada tiene tres partes:

Como [tipo de usuario], quiero [acción u objetivo] para [beneficio o motivo].

De dónde viene la plantilla

Según el glosario de la Agile Alliance, este formato de rol, funcionalidad y beneficio se conoce también como «formato Connextra», por la empresa británica donde surgió en 2001. Mike Cohn, autor de User Stories Applied (Addison-Wesley, 2004), el libro que más hizo por difundir las historias de usuario, atribuye la plantilla a la coach ágil Rachel Davies, que trabajaba en Connextra a comienzos de los años 2000.

Por qué el «para» es la parte más importante

Es la parte que más se omite y la que más valor aporta. El «para» le dice al equipo qué problema hay que resolver, no solo qué hay que construir. Con él, quien desarrolla puede proponer una solución mejor o más simple, y quien prioriza puede comparar historias por el valor que entregan.

Mike Cohn lo ilustra con un ejemplo: si una historia pide un corrector ortográfico y no dice para qué, el equipo podría construir una herramienta que revise el texto al final, cuando lo que el usuario necesitaba era ayuda mientras escribe. Mismo «quiero», necesidades distintas. Cohn también reconoce que en algunos casos muy obvios, como iniciar sesión, el «para» no aporta nada, pero aun así lo incluye en la gran mayoría de las historias que escribe.

Mira cómo cambia una historia cuando el «para» es real:

• ❌ «Como usuario, quiero exportar a Excel para exportar mis datos.» (El «para» repite el «quiero»; no dice nada.)
• ✅ «Como responsable de finanzas, quiero exportar las facturas del mes a Excel para conciliarlas con el extracto bancario sin copiarlas a mano.»

Con la segunda versión, el equipo puede preguntarse: ¿hace falta Excel, o bastaría con conectar directamente con el banco? ¿Qué columnas necesita realmente la conciliación? El «para» abre la conversación que la historia promete.

El «como»: un usuario concreto, no «el usuario»

«Como usuario» es el comodín que vacía de sentido la historia. Un rol específico (cliente nuevo, administrador de cuenta, profesor, repartidor) obliga a pensar en contexto, conocimientos y limitaciones. Si tu equipo trabaja con perfiles definidos, usa sus nombres. Si todavía no los tienen, una proto-persona es un buen punto de partida.

El «quiero»: la necesidad, no la solución

Evita describir la interfaz o la tecnología. «Quiero un botón verde en la esquina superior derecha» es una decisión de diseño disfrazada de historia. «Quiero ver de un vistazo si mi pedido ya salió» deja espacio para que diseño y desarrollo encuentren la mejor solución.

Cómo escribir criterios de aceptación

Los criterios de aceptación son las condiciones que la historia debe cumplir para considerarse terminada. Son la tercera «C», la confirmación, y evitan la frase más cara en desarrollo de producto: «no era esto lo que quería».

Formato de lista simple

Para historias sencillas, una lista de condiciones verificables es suficiente:

Historia: Como cliente frecuente, quiero guardar mi tarjeta para pagar más rápido la próxima vez.

• Al pagar, puedo marcar la opción «Guardar tarjeta para próximas compras».
• En la siguiente compra, la tarjeta guardada aparece seleccionada, mostrando solo los últimos 4 dígitos.
• Puedo eliminar una tarjeta guardada desde mi perfil.
• Si la tarjeta está vencida, se me pide actualizarla antes de pagar.

Formato Dado / Cuando / Entonces

Para comportamientos con varias condiciones, muchos equipos usan el formato Dado / Cuando / Entonces (Given / When / Then), popularizado por el desarrollo guiado por comportamiento (BDD); el glosario de la Agile Alliance lo fecha en 2006. Describe un escenario concreto:

• Dado que tengo una tarjeta guardada que vence este mes,
• cuando intento pagar después de la fecha de vencimiento,
• entonces veo un aviso para actualizar la tarjeta y el pago no se procesa hasta que lo haga.

La ventaja de este formato es que se traduce casi directamente en pruebas automáticas, y obliga a pensar en los casos límite antes de programar.

Qué hace bueno a un criterio de aceptación

• Es verificable: alguien puede comprobar si se cumple o no, sin interpretaciones. «Rápido» no lo es; «carga en menos de 2 segundos en 4G» sí.
• Describe el resultado, no la implementación.
• Cubre los casos límite importantes: errores, datos vacíos, permisos.
• Se acuerda antes de empezar, no después de entregar.

Criterios de aceptación frente a «definición de terminado»

Es fácil confundirlos, pero cumplen funciones distintas. Los criterios de aceptación son específicos de cada historia: describen qué debe hacer esa funcionalidad concreta. La definición de terminado (Definition of Done) es un acuerdo del equipo que se aplica a todas las historias por igual: por ejemplo, que el código esté revisado por otra persona, que tenga pruebas automáticas, que funcione en móvil y que la documentación esté actualizada.

Una historia se considera terminada cuando cumple las dos cosas: sus propios criterios de aceptación y la definición de terminado del equipo. Separarlos tiene una ventaja práctica: no necesitas repetir en cada historia «debe tener pruebas» o «debe funcionar en Chrome y Safari», porque eso ya está en el acuerdo general. Así, los criterios de aceptación quedan cortos y centrados en lo que hace única a cada historia.

Un buen momento para revisar ambos es la sesión de refinamiento del backlog: el equipo lee la historia, hace preguntas, ajusta los criterios y confirma que entiende lo suficiente para estimarla. Si después de esa conversación siguen apareciendo dudas grandes, es señal de que la historia todavía no está lista para entrar en desarrollo.

El checklist INVEST para revisar historias

En agosto de 2003, Bill Wake publicó en su blog XP123 el acrónimo INVEST para recordar las características de una buena historia. Sigue siendo el filtro más práctico para revisar un backlog:

Letra	Significa	Pregunta de control	Señal de alarma
I	Independiente	¿Se puede construir y entregar sin esperar a otra historia?	«Esta depende de la 14, que depende de la 9…»
N	Negociable	¿Deja espacio para que el equipo proponga cómo resolverla?	Describe la pantalla píxel a píxel
V	Valiosa	¿Entrega algo útil a un usuario o al negocio?	«Migrar la base de datos» sin beneficio visible
E	Estimable	¿El equipo entiende lo suficiente para estimarla?	Nadie sabe por dónde empezar
S	Pequeña (Small)	¿Cabe cómodamente en una iteración?	«Esta nos va a llevar todo el trimestre»
T	Testeable	¿Se puede comprobar que está terminada?	«El sistema debe ser intuitivo»

Wake resume la «T» con una frase muy útil: entiendo lo que quiero lo suficientemente bien como para poder escribir una prueba. Si no puedes imaginar cómo comprobarías que la historia está hecha, todavía no está lista.

Ejemplos de historias de usuario: buenas y malas

Ver la diferencia en ejemplos concretos es la forma más rápida de aprender. Estos son casos típicos en distintos tipos de producto:

Producto	Versión floja	Versión mejorada
App de delivery	Como usuario, quiero notificaciones.	Como cliente que espera un pedido, quiero recibir un aviso cuando el repartidor esté a 5 minutos para bajar a recibirlo sin esperar en la puerta.
Plataforma educativa	Como alumno, quiero un buscador.	Como alumno que repasa para un examen, quiero buscar un concepto dentro de las clases que ya vi para volver al minuto exacto donde se explicó.
Software de RR. HH.	Como admin, quiero un informe de vacaciones.	Como responsable de equipo, quiero ver en un calendario quién está de vacaciones el próximo mes para no aprobar ausencias que dejen el turno sin cobertura.
Tienda online	Como usuario, quiero filtros.	Como comprador de ropa, quiero filtrar por talla disponible para no perder tiempo en prendas que no hay en mi talla.

Fíjate en el patrón: las versiones mejoradas tienen un rol con contexto, una necesidad clara y un «para» que explica el problema real. Con eso, el equipo puede discutir soluciones alternativas y escribir criterios de aceptación.

Cómo dividir una historia demasiado grande

Una historia demasiado grande es en realidad una épica. El error típico es dividirla por capas técnicas (primero la base de datos, luego el servidor, luego la pantalla), lo que produce partes que no entregan valor hasta el final. Bill Wake recomienda lo contrario: cortes «verticales» que atraviesen todas las capas y entreguen algo usable.

Formas útiles de dividir

• Por pasos del flujo: «buscar vuelos» antes que «comparar» y «reservar».
• Por reglas de negocio: primero el pago con tarjeta; después, transferencia y otros medios.
• Por tipo de usuario: primero para clientes nuevos, después para empresas.
• Por variación de datos: primero un idioma o una moneda; después, los demás.
• Por el camino feliz primero: el caso sin errores, y en historias siguientes los casos excepcionales.

Este enfoque se parece mucho a la lógica del producto mínimo viable: entregar pronto algo pequeño que funcione de punta a punta y aprender de él.

Cómo usar la IA para mejorar tus historias de usuario (sin delegarle el criterio)

Los asistentes de IA son muy buenos revisores de texto: detectan ambigüedades, roles genéricos, «para» vacíos y historias que mezclan varias necesidades. Lo que no pueden hacer es decidir qué es valioso para tus usuarios, porque no estuvieron en las entrevistas ni conocen tu estrategia. Úsala como un colega crítico, no como el dueño del backlog.

Prompt para auditar un backlog

«Actúa como un product manager experimentado que revisa historias de usuario. Te paso 10 historias de nuestro backlog [pégalas]. Contexto: [producto, tipo de usuarios, objetivo del trimestre]. Para cada historia: 1) indica si cumple cada criterio INVEST y por qué; 2) señala si el rol es genérico o si el «para» repite el «quiero»; 3) si es demasiado grande, propón 2 o 3 cortes verticales; 4) sugiere 3 a 5 criterios de aceptación verificables. No inventes necesidades que no estén en el texto: si falta información, formula la pregunta que haría falta hacerle al usuario.»

Dónde ayuda la IA y dónde decides tú

Tarea	La IA puede…	Tú decides…
Redacción	Detectar ambigüedades, roles genéricos y «para» vacíos	Qué necesidad real hay detrás
Tamaño	Proponer formas de dividir una historia grande	Qué corte entrega más valor primero
Criterios de aceptación	Sugerir casos límite que olvidaste	Cuáles son imprescindibles y cuáles sobran
Priorización	Ordenar según un criterio que tú le des	El criterio, y la decisión final
Investigación	Resumir notas de entrevistas	Qué patrones son reales y cuáles son ruido

Dos precauciones: no pegues datos personales de clientes ni información confidencial en herramientas que no estén aprobadas por tu empresa, y revisa siempre lo que la IA propone. Un asistente puede sonar muy seguro mientras inventa una necesidad que ningún usuario expresó. Para evitarlo, la pregunta «¿de qué entrevista o dato sale esto?» es tu mejor filtro, y el product discovery es la práctica que la responde.

Errores comunes al escribir historias de usuario

• Usar «como usuario» en todas. Si todas las historias tienen el mismo rol, el rol no aporta información.
• «Para» que repite el «quiero». «Quiero filtrar para filtrar» no explica ningún problema.
• Historias técnicas disfrazadas. «Como desarrollador, quiero refactorizar el módulo…» puede ser trabajo necesario, pero conviene tratarlo como tarea o deuda técnica y explicar su valor.
• Escribir la solución en lugar de la necesidad. Le quita al equipo la posibilidad de encontrar algo mejor.
• Olvidar los criterios de aceptación. Sin ellos, «terminado» significa algo distinto para cada persona.
• Escribirlas en soledad. Las historias se refinan en conversación con diseño y desarrollo; si solo una persona las escribe y las entrega, se pierde la segunda «C».

Una alternativa: las job stories

Algunos equipos prefieren las job stories, que ponen el foco en la situación en lugar del rol: «Cuando [situación], quiero [motivación] para [resultado esperado]». Este formato nace de la teoría de los jobs to be done. Si te interesa, revisa nuestra guía sobre la metodología JTBD. No es un formato mejor ni peor: es otra forma de obligarte a pensar en el «para».

Ejercicio práctico: mejora 5 historias de tu backlog en 45 minutos

1. Elige (5 minutos). Toma 5 historias de tu backlog actual que vayan a entrar pronto en desarrollo.
2. Revisa el «para» (10 minutos). Para cada una, pregúntate: ¿qué problema resuelve? Si el «para» está vacío o repite el «quiero», reescríbelo. Si no sabes el motivo, anota la pregunta y llévala a la próxima conversación con un usuario.
3. Pasa el INVEST (10 minutos). Marca qué letras cumple cada historia. Las que fallen en «S» o «T» son prioridad para dividir o aclarar.
4. Usa la IA como segundo revisor (10 minutos). Pega las 5 historias con el prompt de esta guía y compara sus observaciones con las tuyas. Quédate solo con las que tengan sentido para tu contexto.
5. Escribe criterios de aceptación (10 minutos). Al menos 3 por historia, verificables. Luego revísalos con alguien de desarrollo.

Repite el ejercicio en cada refinamiento del backlog. En pocas semanas notarás menos idas y vueltas y menos funcionalidades que «no eran lo que se pedía». Para ver cómo encajan estas historias en una planificación mayor, mira cómo hacer un roadmap de producto.

Cómo lo aprendes en Pulsión Digital

Las historias de usuario son una pieza del trabajo diario de un product manager. En el curso Product Manager con IA de Pulsión Digital las conectas con todo el ciclo de producto, siguiendo un caso práctico de principio a fin:

• Descubrimiento: hablar con usuarios y sintetizar con IA sin perder los matices.
• Priorización con IA: RICE y Kano aplicados a un backlog real.
• Escribir PRDs con IA: documentos de requisitos claros que diseño y desarrollo puedan ejecutar.
• Trabajar con diseño y desarrollo: participar del refinamiento del backlog y traducir entre negocio y tecnología.
• Métricas de producto y un ciclo que se repite cada sprint.

Lo haces a tu propio ritmo, con un examen en cada clase, un tutor con IA que responde tus dudas, una comunidad de personas con intereses parecidos y un certificado al terminar.

Si coordinas equipos y plazos, el curso de Project Manager complementa esta mirada. Y si quieres profundizar en entender a los usuarios, el de UX Design te enseña a investigar y diseñar desde sus necesidades. Para entender el rol completo, empieza por qué es un product manager.

Preguntas frecuentes sobre historias de usuario

¿Qué es una historia de usuario?

Es una descripción breve de una funcionalidad escrita desde el punto de vista de quien la va a usar, normalmente con la plantilla «Como [usuario], quiero [acción] para [beneficio]», acompañada de criterios de aceptación.

¿Cuál es la estructura de una historia de usuario?

Tiene tres partes: el rol (quién), la acción u objetivo (qué) y el beneficio (para qué). Se completa con criterios de aceptación que indican cuándo la historia está terminada.

¿Qué son los criterios de aceptación?

Son las condiciones verificables que la historia debe cumplir para considerarse terminada. Pueden escribirse como una lista o con el formato Dado / Cuando / Entonces.

¿Qué significa INVEST en historias de usuario?

Es un acrónimo creado por Bill Wake en 2003: Independiente, Negociable, Valiosa, Estimable, Pequeña (Small) y Testeable. Sirve como checklist para revisar si una historia está lista.

¿Quién escribe las historias de usuario?

Suele hacerlo el product manager o el product owner, pero se refinan en conversación con diseño y desarrollo. Cualquier persona del equipo puede proponer una historia.

¿Puede la IA escribir historias de usuario?

Puede redactar borradores, detectar historias vagas o demasiado grandes y sugerir criterios de aceptación. Pero la decisión sobre qué necesidad es real y qué aporta más valor debe basarse en tus usuarios y la tomas tú.

Conclusión

Aprender cómo escribir historias de usuario no consiste en dominar una plantilla, sino en adquirir el hábito de preguntar «¿para qué?» antes de construir. Un rol concreto, una necesidad clara, un beneficio real y criterios de aceptación verificables convierten una tarjeta corta en una conversación productiva. El checklist INVEST te ayuda a revisar y la IA te ahorra tiempo como revisora, pero el criterio de producto, saber qué vale la pena construir, sigue siendo la parte humana del trabajo.

Fuentes consultadas

• Agile Alliance. User Story Template y User Stories (glosario).
• Mike Cohn, Mountain Goat Software. User Story Template: What It Is and Why It Works So Well.
• Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
• Ron Jeffries (30 de agosto de 2001). Essential XP: Card, Conversation, Confirmation.
• Bill Wake (agosto de 2003). INVEST in Good Stories, and SMART Tasks.