User Stories: Cómo Escribirlas con Ejemplos Reales

El formato básico

El formato estándar tiene tres componentes que responden quién, qué y por qué:

Como [tipo de usuario],
quiero [realizar una acción],
para [obtener un beneficio].

La parte más ignorada y más importante es el "para qué". Sin el beneficio, no sabes si la solución propuesta es la correcta. "Quiero un botón de exportar" no te dice nada. "Para poder compartir el reporte con mi jefe que no tiene acceso al sistema" te dice todo.

Ejemplos por tipo de producto

E-commerce

US-001: Como comprador frecuente,
quiero guardar mi dirección de envío,
para no tener que ingresarla cada vez que compro.

Criterios de aceptación:
- Given: usuario logueado con 0 direcciones guardadas
  When: completa el checkout por primera vez
  Then: el sistema pregunta si quiere guardar la dirección

- Given: usuario con 3 direcciones guardadas
  When: inicia un nuevo checkout
  Then: puede seleccionar una dirección existente o agregar nueva

- Given: usuario quiere eliminar una dirección
  When: va a configuración > direcciones > eliminar
  Then: se elimina la dirección y no aparece en futuros checkouts

App de finanzas personales

US-002: Como usuario que quiere controlar sus gastos,
quiero ver un resumen mensual categorizado,
para identificar en qué estoy gastando más.

Criterios de aceptación:
- Given: usuario con 15+ transacciones en el mes
  When: abre la vista de resumen mensual
  Then: ve un gráfico de torta con categorías y montos

- Given: usuario sin transacciones en el mes
  When: abre el resumen
  Then: ve un estado vacío con CTA para registrar su primer gasto

- Given: una transacción no tiene categoría asignada
  When: se genera el resumen
  Then: aparece bajo "Sin categorizar" con opción de asignar

SaaS B2B

US-003: Como administrador de equipo,
quiero invitar miembros por email con roles predefinidos,
para controlar los permisos sin necesidad de soporte técnico.

Criterios de aceptación:
- Given: admin con plan que permite hasta 10 usuarios
  When: envía invitación al usuario #11
  Then: ve mensaje de upgrade con comparación de planes

- Given: admin envía invitación a email ya registrado
  When: el invitado hace click en el link
  Then: se asocia a su cuenta existente sin crear duplicado

- Given: invitación enviada hace más de 7 días
  When: el invitado intenta usarla
  Then: ve mensaje de expiración con opción de solicitar nueva

El framework INVEST

INVEST es el checklist para validar que una user story está bien escrita. Si falla en cualquiera de estos criterios, necesita refinamiento:

Given-When-Then: Acceptance criteria que funcionan

El formato Given-When-Then (también llamado Gherkin) transforma criterios ambiguos en escenarios verificables:

• Given (Dado): el contexto o estado inicial — qué condiciones existen antes de la acción
• When (Cuando): la acción que el usuario realiza — el trigger
• Then (Entonces): el resultado esperado — qué debe pasar

Errores comunes

Story demasiado grande (epic disfrazada)

"Como usuario, quiero un sistema de pagos completo" — eso no es una story, es un proyecto de 3 meses. Si tu story no cabe en un sprint, descomponla. La regla: si no puedes demo-ear el resultado en la sprint review, es demasiado grande.

Story técnica sin valor para el usuario

"Como desarrollador, quiero migrar la base de datos a PostgreSQL" — esto es una tarea técnica, no una user story. Las tareas técnicas son válidas, pero no las disfraces como stories. Si necesitas hacerla, explica el beneficio: "para que los reportes que hoy tardan 30 segundos carguen en 3 segundos".

Acceptance criteria que nadie puede testear

"La experiencia debe ser fluida y rápida" — ¿qué significa "fluida"? ¿"Rápida" es menos de 1 segundo o menos de 5? Los criterios deben ser binarios: pasa o no pasa. Si no puedes automatizar el test, al menos debes poder verificar manualmente sin ambigüedad.