Resumen ejecutivo

• Una historia de usuario describe una necesidad desde la mirada de quien usa el producto: "Como [usuario], quiero [acción], para [beneficio]".

• El checklist INVEST te ayuda a saber si una historia está bien escrita: independiente, negociable, valiosa, estimable, pequeña y testeable.

• Los criterios de aceptación con formato Given/When/Then (Dado/Cuando/Entonces) convierten la historia en algo verificable por desarrollo y QA.

• La IA sirve para un primer borrador, pero el criterio de producto (qué valor aporta y qué queda afuera) sigue siendo tuyo.

Escribir historias de usuario parece fácil hasta que tenés que hacerlo para un equipo real: aparecen historias gigantes, criterios ambiguos y discusiones en la planning sobre qué significaba "que funcione bien". El ángulo de esta guía es práctico: plantilla, checklist de calidad, criterios de aceptación con ejemplos y cómo partir una épica. ¿Por qué ahora? Porque escribir historias de usuario es una de las habilidades que más se evalúan en entrevistas de Product Owner y Product Manager, y es la base para aplicar Scrum de verdad. Si querés ubicarte primero en el rol, leé qué hace un Product Owner y cuáles son sus funciones.

La plantilla básica

El formato más usado tiene tres partes:

• Como [tipo de usuario]: quién tiene la necesidad.

• Quiero [acción o capacidad]: qué quiere hacer.

• Para [beneficio]: por qué le importa.

La parte del "para" es la que más se omite y la más importante: es la que permite discutir alternativas. Atlassian la describe como una explicación informal de una funcionalidad escrita desde la perspectiva del usuario final, cuyo objetivo es articular cómo esa funcionalidad le aporta valor.

Checklist INVEST: cómo saber si una historia está bien

El acrónimo INVEST, propuesto por Bill Wake y recogido por la Agile Alliance, resume seis criterios de calidad:

1. Independiente: se puede desarrollar sin depender de otra historia.

2. Negociable: no es un contrato cerrado; el detalle se conversa con el equipo.

3. Valiosa: aporta algo concreto al usuario o al negocio.

4. Estimable: el equipo puede calcular su esfuerzo de forma aproximada.

5. Pequeña (Small): entra en una iteración.

6. Testeable: se puede comprobar si está terminada.

Criterios de aceptación con Given/When/Then

Los criterios de aceptación definen cuándo la historia está terminada. El formato Given/When/Then viene de Gherkin, el lenguaje que usa Cucumber para describir comportamientos que después se pueden automatizar como tests:

• Dado (Given) un contexto inicial,

• Cuando (When) ocurre una acción,

• Entonces (Then) se espera un resultado observable.

Ejemplo 1: app de turnos médicos

Como paciente, quiero recibir un recordatorio del turno el día anterior, para no olvidarme y no perder la consulta.

• Dado que tengo un turno confirmado para mañana, cuando son las 10 de la mañana del día anterior, entonces recibo una notificación con fecha, hora y profesional.

• Dado que cancelé el turno, cuando llega el horario del recordatorio, entonces no recibo ninguna notificación.

• Dado que desactivé las notificaciones, cuando llega el horario del recordatorio, entonces recibo el aviso por mail.

Ejemplo 2: e-commerce

Como comprador, quiero guardar productos en una lista de favoritos, para comprarlos más adelante sin volver a buscarlos.

• Dado que inicié sesión, cuando toco el ícono de corazón en un producto, entonces el producto aparece en mi lista de favoritos.

• Dado que no inicié sesión, cuando toco el ícono de corazón, entonces se me pide iniciar sesión y, al hacerlo, el producto queda guardado.

• Dado que un producto de mi lista se quedó sin stock, cuando abro favoritos, entonces lo veo marcado como "sin stock".

Cómo partir una épica en historias

Una épica es una necesidad grande que no entra en una iteración, como "pagar con distintos medios". Algunas formas de partirla:

• Por flujo: elegir medio de pago, pagar con tarjeta, pagar con transferencia, ver el comprobante.

• Por tipo de usuario: comprador nuevo vs comprador frecuente con tarjeta guardada.

• Por regla de negocio: pago en una cuota primero, cuotas después.

• Por camino feliz y excepciones: pago aprobado primero, rechazos y reintentos después.

Para ver el recorrido completo antes de partir, una técnica muy útil es el User Story Mapping.

Errores comunes

• Escribir tareas técnicas como historias ("crear tabla de usuarios").

• Historias sin "para": no se puede priorizar lo que no tiene valor explícito.

• Criterios vagos como "que sea rápido" o "que se vea bien".

• Historias que solo entiende quien las escribió: tienen que ser conversación con el equipo, no un documento cerrado.

Cómo usar IA para un primer borrador sin perder criterio

Un asistente de IA puede acelerar mucho la primera versión. Probá un prompt así: "Actuá como Product Owner. A partir de esta necesidad: [descripción], proponé de 3 a 5 historias de usuario con formato Como/Quiero/Para y 3 criterios de aceptación Given/When/Then para cada una. Señalá supuestos y preguntas abiertas."

Después, revisá con INVEST, eliminá lo que no aporta valor y validá los supuestos con usuarios y con el equipo. La IA no conoce tu negocio ni tus prioridades: el borrador es un punto de partida. Para encajar todo esto en el trabajo del equipo, mirá Scrum en la práctica; y si querés repasar el marco oficial, la Guía de Scrum explica cómo se gestiona el Product Backlog.

Cursos recomendados de Coderhouse

El Curso de Product Manager trabaja backlog, priorización y roadmap con casos reales. Si querés profundizar en el marco ágil, el Curso de Scrum - Metodologías Ágiles te prepara para el día a día del equipo. Y para un camino completo, mirá la Carrera de Producto.

CTA: tomá una funcionalidad de una app que uses todos los días, escribí tres historias con sus criterios de aceptación y pasalas por el checklist INVEST. Es un excelente ejercicio para tu portfolio de producto, y en el Curso de Product Manager de Coderhouse lo practicás con feedback.

Preguntas frecuentes

¿Quién escribe las historias de usuario? Normalmente el Product Owner es responsable del backlog, pero las historias se refinan en conjunto con el equipo de desarrollo, diseño y QA.

¿Cuántos criterios de aceptación debería tener una historia? No hay un número fijo; entre tres y cinco suele alcanzar. Si necesitás muchos más, probablemente la historia es demasiado grande.

¿Qué diferencia hay entre una historia de usuario y una épica? La épica es una necesidad grande que se divide en varias historias que entran en una iteración.

¿Es obligatorio usar Given/When/Then? No, pero ayuda a que los criterios sean concretos y fáciles de convertir en pruebas.