Historias de usuario: formato y cómo cortarlas

Una historia de usuario (o user story) es la descripción corta de una necesidad, contada desde la perspectiva de quien la vive, junto con el criterio que permite verificar que quedó resuelta. Nació en metodologías ágiles de software (Extreme Programming, luego Scrum), pero el formato sirve para cualquier equipo que entrega trabajo: producto, contenido, servicios.

El formato clásico tiene tres partes, y cada una cumple una función:

La historia completa: “Como coordinadora de proyectos, quiero ver qué tareas están bloqueadas, para desbloquear el trabajo sin preguntar en el chat”. Si no puedes escribir la parte del para, la historia probablemente no vale la pena: sin beneficio no hay prioridad posible.

• No es una especificación. La historia es una promesa de conversación: el detalle se acuerda con quien pide, no se ha escrito todo de antemano. Si tu “historia” tiene 15 requisitos numerados, es una especificación con formato ágil.
• No es una tarea técnica. “Refactorizar el módulo de pagos” no tiene rol ni beneficio de usuario: es una tarea (legítima, pero otra cosa). Las tareas técnicas viven igual en el tablero, sin fingir que alguien las pidió “como usuario”.
• No es un épico eterno. El épico agrupa historias grandes (“mejorar el onboarding”); la historia es lo que entra al trabajo y termina. El error clásico es un épico que lleva 6 meses “en progreso” porque nunca se cortó en piezas.

Y una historia no está “hecha” cuando el código (o el diseño, o el texto) está listo: está hecha cuando cumple sus criterios de aceptación. Ese checklist de cierre compartido por todo el equipo —la definition of done— es el complemento de la historia: sin él, cada persona decide cuándo algo cuenta como terminado.

Los criterios de aceptación son las condiciones verificables que cumplen para dar la historia por terminada. Viven en la tarjeta, escritos antes de empezar el trabajo. Sin ellos, “hecho” se discute a fin de mes; con ellos, se verifica en 30 segundos.

Para la historia de arriba, por ejemplo:

• Existe una vista o filtro “bloqueadas” accesible desde la pantalla principal.
• Cada tarjeta bloqueada muestra por qué espera (quién y desde cuándo).
• La coordinadora la encuentra sin pedir ayuda en menos de 30 segundos (prueba con 2 personas reales).

Nota el último: un criterio que se puede fallar. “Debe ser fácil de usar” no es un criterio; es una opinión. Si no sabes cómo verificarlo, no es criterio de aceptación.

La pregunta del tamaño: ¿esto lo termina una persona en pocos días, con lo que sabe hoy? Si la respuesta es no, hay que cortar. Cinco cortes que casi siempre sirven, aplicados a “como cliente, quiero gestionar mi cuenta”:

1. Por pasos del recorrido. Crear cuenta / editar datos / cerrar cuenta. Cada paso es una historia.
2. Por flujo feliz primero. Primero “crear cuenta con email”; después “crear cuenta con Google”, después la recuperación. El caso ideal entra antes que los bordes.
3. Por reglas de negocio. “Editar datos” con validaciones básicas, después con las reglas fiscales del país X, después del país Y.
4. Por variación de rol. “Ver reportes” como coordinadora primero; como gerente, después. Mismas piezas, usuarios distintos.
5. Por calidad gradual. Funciona lento pero completo, después se optimiza. A veces el corte honesto es “versión fea que resuelve” vs. “versión pulida”.

Fuera de software funcionan igual: “lanzar la campaña de diciembre” no es una historia; “publicar la landing de la campaña” sí, y el corte por pasos la separa de “configurar el email de aviso” y “preparar el reporte semanal”. Las historias cortas alimentan el backlog y hacen posible comprometer un sprint real (cómo se hace ese compromiso en Sprint planning que se cumple).

El formato “como… quiero… para…” parece jerga de developers, pero su valor — fijar quién pide y para qué antes de trabajar— aplica a cualquier estudio o agencia. Dos ejemplos:

• Estudio de diseño: “Como directora de la agencia, quiero un resumen del estado de cada cuenta en una página, para preparar la reunión del lunes sin abrir 6 tableros.” Criterios: cubre las 6 cuentas, cabe en una página, se actualiza solo.
• Pyme de servicios: “Como cliente de la pyme, quiero confirmar por escrito la fecha de mi visita, para no estar pendiente del teléfono.” Criterios: confirmación automática al agendar, con opción de reprogramar desde el mensaje.

En ambos casos, la historia hizo dos favores: obligó a nombrar al usuario real (no “el cliente” abstracto) y puso el beneficio antes del entregable. Ese mismo orden —quién, qué, para qué— es lo que después permite priorizar sin discutir gustos: los roles y las aprobaciones se ordenan aparte, con una matriz RACI.

Si quieres escribir historias y seguir su recorrido en un tablero que vive en tu carpeta —JSON local, sin cuenta ni asientos— Hito es un gestor local-first para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — tablero kanban, backlog y procesos en tu propio equipo. Sin nube, sin cuenta.