Desglosar épicas en historias de usuario con IA (sin perder el criterio)

Tiempo de lectura: 7 minutos

Desglosar una épica en historias es de las tareas que más semana consumen a un Product Owner, y donde antes se nota una IA bien usada: la tarde de refinamiento en blanco se convierte en un borrador de siete historias en dos minutos. El matiz está en la palabra borrador — ese primer corte, tal cual sale, no se lleva al equipo nunca.

Lo vemos con el caso que usamos en formación: GymTonic, una cadena de gimnasios, y GymApp, su app de socios. Nuria, su Product Owner, tiene sobre la mesa la épica "Reservar y cancelar clases sin fricción": sale de los dos temas más repetidos en la última encuesta a socios —la app va lenta al reservar y cancelar es un lío— y conecta con una métrica que ya mira la dirección, la activación de socios nuevos (40% → 60%).

Los tres ingredientes de un prompt de desglose que funciona

Un primer corte útil no sale de pedir "divídeme esta épica". Necesita tres piezas, siempre en este orden:

• La épica, en una frase, con el outcome que persigue — no una lista de tareas técnicas.
• Tu documento de contexto de producto: visión, quién es el usuario, las métricas que mueven decisiones y el vocabulario del dominio (socio, clase, franja horaria, lista de espera, cuota). Sin él, la IA te devuelve un producto de reservas genérico que podría ser de cualquier gimnasio del mundo. Es la diferencia que explica la ingeniería de contexto: el contexto marca más que el prompt.
• El formato de salida: historias en "Como… quiero… para…", con estimación relativa de tamaño (S/M/L) y las dependencias que la IA detecte.

Así queda el prompt de Nuria, listo para adaptar:

Actúa como asistente de refinamiento de producto. Te paso el documento de contexto de mi producto y una épica. Quiero un primer corte de historias de usuario para llevar a refinamiento con el equipo.
[pega aquí tu documento de contexto de producto]
Épica: "Reservar y cancelar clases sin fricción en GymApp". Motivo: son los dos temas de queja más repetidos en la última encuesta, y afectan a la activación de socios nuevos.
Dame:
- Entre 5 y 8 historias en formato "Como [rol] quiero [acción] para [beneficio]".
- Una estimación relativa de tamaño por historia (S/M/L), solo el orden de magnitud.
- Las dependencias que veas entre historias, si las hay.
No añadas historias de infraestructura o backend salvo que sean imprescindibles para que una historia de usuario funcione.

Y esto es lo que devuelve — siete historias que a primera vista se leen muy bien:

• Ver el horario de clases con el aforo restante, para decidir a cuál apuntarse. [M]
• Reservar una clase en un solo paso. [S]
• Cancelar mi reserva para liberar la plaza si al final no puedo ir. [S]
• Como sistema, cachear la consulta de disponibilidad para que el horario cargue en menos de 1 segundo. [M]
• Gestionar todas mis reservas, cancelaciones y lista de espera desde un panel único. [L]
• Recibir una notificación cuando se libera una plaza en una clase con lista de espera. [S]
• Ver cuánto aforo queda en una clase antes de reservar. [S]

Se leen bien, sí. Y aquí es donde empieza el trabajo de verdad.

Los tres defectos que trae siempre un primer corte

No son fallos de la IA: son exactamente el trabajo que le toca al PO. Pero se repiten tanto que conviene saber buscarlos.

1. La historia "capa técnica"

Es la cuarta de la lista: "Como sistema, cachear la consulta de disponibilidad…". "El sistema" no es un rol de negocio, y eso no aporta valor que un socio note por separado. Pero no la tires: el requisito de rendimiento es legítimo, lo que falla es el formato y el sitio. Según su alcance, tiene tres destinos:

• Criterio de aceptación de la historia a la que sirve, si el requisito es de esa funcionalidad concreta.
• Definition of Done, si es transversal a todo el producto. Si exiges que cualquier pantalla cargue por debajo de un segundo, eso se acuerda una vez con el equipo, no historia por historia. Si esta distinción te baila, la desarrollamos en Definición de Done y criterio de aceptación.
• Tarea o historia técnica propia, si el trabajo es lo bastante grande para merecer su hueco y su conversación de priorización.

Y de paso, una idea que el formato "Como… quiero… para…" hace olvidar: no todo lo que vive en un backlog tiene que ser una épica o una historia de usuario. Deuda técnica, spikes, bugs y requisitos legales son trabajo legítimo que se gestiona con otros formatos sin dejar de estar priorizado.

2. Tamaños que no cuadran

La del panel único viene como L: en realidad son tres o cuatro historias en una. Y la última, ver el aforo restante, viene como S… y además es redundante, porque ya está cubierta por la primera. Un L gigante junto a una S que no debería existir aparte delata que la IA ha enumerado, no ha aplicado criterio de corte. Las técnicas para partir bien no cambian por usar IA: cómo descomponer bien las épicas.

3. La dependencia oculta

La notificación de plaza libre depende de que exista "apuntarse a la lista de espera"… que la IA no ha propuesto. Si entra a un Sprint sin la otra construida, el equipo se topa con el bloqueo a mitad de desarrollo, no antes.

La IA como auditora, no solo como autora

Este es el cambio de uso que más tiempo ahorra, y casi nadie lo hace: en vez de pedirle que genere, pídele que diagnostique.

Funciona igual con historias escritas a mano: le pegas lo que ya tenías y pides la misma auditoría. Para el repaso previo de qué hace buena a una historia, la guía definitiva; para el siguiente nivel de detalle, buenos criterios de aceptación.

Lo que no se delega, por muy bueno que sea el borrador

Hay tres situaciones donde el problema no es cómo se redacta la historia, sino quién decide:

• Épicas con carga política. Si dirección plantea penalizar al socio que cancela con menos de dos horas, eso no es una historia: es una decisión de relación con el cliente. Pedir "dame la historia de penalización" antes de que esa decisión exista es delegar el negocio en una herramienta sin autoridad ni contexto.
• Alcance que hay que negociar. La IA te prepara los argumentos y los trade-offs para la conversación con Operaciones. No puede tener la conversación.
• Cuando el corte es la decisión estratégica. Si la pregunta real es "¿hacemos esta épica ahora o priorizamos otra?", usar un prompt de desglose para esquivar esa conversación es el error de fondo.

La frontera no es "IA sí / IA no". Es: ¿quién decide el qué, y quién solo redacta el cómo?

Por dónde empezar esta semana

Coge una épica real de tu backlog, monta el prompt con las tres piezas y pásale la auditoría INVEST al resultado: en media hora sabrás si esto te sirve. Para no partir de cero tienes gratis la biblioteca de prompts para Product Owners, con los flujos ya redactados, y el test ¿qué tipo de PO eres?.

¿Historias con tanta regla de negocio que el formato "Como… quiero… para…" se queda corto? Entonces el camino es una especificación completa: Specification-Driven Development. ¿Y si lo que falla es decidir qué construir antes que cómo partirlo? Métricas de producto: del output al outcome.

Recursos relacionados

• Cómo descomponer bien las épicas en historias de usuario
• La guía definitiva para escribir buenas historias de usuario
• Escribir historias de usuario con buenos criterios de aceptación
• Definición de Done y criterio de aceptación
• 5 prompts de IA que potencian a un Product Owner
• Ingeniería de contexto: por qué ya no basta con saber preguntar
• Biblioteca de prompts para Product Owners — gratis