Llevo unos meses haciendo coaching con los equipos de producto de una multinacional. Una de las primeras cosas que salta a la vista en este tipo de organizaciones es la cantidad de trabajo que se mueve en el backlog sin que nadie tenga claro hacia dónde va ni si está generando el valor esperado.
Los síntomas eran reconocibles: las prioridades cambiaban con demasiada frecuencia, las épicas tardaban meses en completarse, y cuando por fin se entregaba algo, nadie había definido previamente qué hipótesis se estaba validando ni cómo se mediría el resultado. El equipo ejecutaba con diligencia, pero sin brújula.
El problema no era falta de capacidad. Era estructural: la épica existía como idea, pero el camino desde esa idea hasta el backlog ejecutable era un terreno de nadie. Nadie sabía cuándo una épica estaba lista para descomponerse, con qué criterio hacerlo, ni cómo saber después si había valido la pena.
Este artículo recoge las ideas que más han ayudado en ese proceso. Los ejemplos son de GymTonic, una cadena de gimnasios ficticia que uso en mis formaciones para ilustrar situaciones parecidas a las que he encontrado en clientes reales.
Por qué existe el formato de historia de usuario
Antes de hablar de épicas, vale la pena recordar por qué nació el formato de historia de usuario — porque se usa mal precisamente cuando se olvida su propósito original.
La historia de usuario no nació como una plantilla de especificación. Nació como una conversación aplazada.
En los equipos tradicionales, los requisitos viajaban en documentos: un analista escribía lo que el sistema debía hacer, el documento pasaba a desarrollo, y el equipo construía lo que decía el papel. El resultado era predecible: lo construido no siempre era lo que el usuario necesitaba, porque en el camino se había perdido el contexto, el matiz, la intención real.
Las historias de usuario proponen algo diferente: en lugar de especificar la solución en un documento, anota lo suficiente para recordar que hay una conversación pendiente entre quien tiene el conocimiento del problema — el usuario, el stakeholder — y el equipo que va a construir la solución. La historia es la excusa para esa conversación, no su sustituto.
El formato clásico ("Como [rol], quiero [acción], para [beneficio]") no es lo importante. Lo que importa es que la historia:
- Identifica a una persona real con un problema real, no a "el usuario" en abstracto.
- Describe una necesidad, no una solución. Deja espacio para que el equipo proponga cómo resolverla.
- Explicita el para qué, el impacto esperado que da sentido a todo lo demás.
Sin esto, las historias se convierten en tareas técnicas con una careta de usuario pegada encima.
Para ver cómo integrar la perspectiva del usuario en las historias desde el diseño de experiencia, puedes leer How to Integrate Scrum and UX with Dual-Track Scrum, donde explico cómo combinar discovery y delivery en Scrum.
No todos los ítems del backlog son historias de usuario
Antes de entrar en la descomposición, hay un malentendido frecuente que conviene aclarar: el backlog no es una lista de historias de usuario. Es una lista de ítems de trabajo de diferentes tipos.
Las historias de usuario son el formato apropiado cuando hay una necesidad de usuario que entender en profundidad, cuando la conversación entre quien tiene el problema y el equipo que construye la solución es imprescindible. Pero hay trabajo en el backlog que no requiere esa conversación:
- Defectos o bugs: algo que debería funcionar y no funciona. Lo relevante es la descripción del comportamiento incorrecto y los pasos para reproducirlo, no un formato de historia.
- Tareas técnicas: refactorizaciones, mejoras de rendimiento, actualizaciones de dependencias, configuraciones de infraestructura. Son trabajo legítimo, pero no tienen un usuario final con una necesidad que explorar.
- Spikes o investigaciones: trabajo cuyo objetivo es reducir incertidumbre técnica o de producto. El output no es software funcionando, sino conocimiento.
Forzar todos estos ítems al formato de historia no añade valor — lo resta. La pregunta que hay que hacerse antes de escribir cualquier ítem es: ¿hay aquí una necesidad de usuario que necesitamos entender mejor hablando con alguien? Si la respuesta es sí, la historia tiene sentido. Si no, usa el formato que mejor describa el trabajo.
En GymTonic, la migración de la base de datos de socios al nuevo sistema era una tarea técnica. Nadie la escribió como historia. Pero la funcionalidad de reactivación de socios inactivos sí requería entender qué motivaba a un socio a volver después de semanas sin venir — y ahí el formato de historia era imprescindible.
La jerarquía Why / What / How
Para entender cómo pasar de una épica a historias, es útil pensar en tres niveles que responden a preguntas distintas.
Why — La épica
La épica responde al por qué. No es una historia grande ni simplemente una agrupación de historias: es la representación de una necesidad o de un valor potencial que aún tiene suficiente incertidumbre como para no poder planificarse directamente en sprints. Suele requerir descomponerse en varias historias para poder entenderse y ejecutarse de manera incremental.
Una épica bien formulada incluye:
- El problema de negocio o de usuario que justifica la iniciativa
- El caso de negocio: qué impacto esperamos y por qué merece la inversión
- La hipótesis que queremos validar: ¿qué creemos que pasará si resolvemos este problema?
- Las métricas que usaremos para saber si ha funcionado
- Las restricciones o dependencias conocidas
En GymTonic, una épica bien definida sonaba así:
"Los socios que llevan más de 3 meses sin venir al gimnasio tienen una tasa de baja del 60% en los siguientes 30 días. Creemos que si les contactamos de manera personalizada antes de ese punto, podemos reactivar al menos al 20% de ellos. Métricas clave: tasa de reactivación, tiempo medio hasta la primera visita tras el contacto, tasa de baja a 90 días."
Esto es una épica. Tiene un problema claro, una hipótesis explícita y métricas que permiten evaluar si la solución funciona. Sin este nivel de claridad, todo lo que viene después es ruido — y los cambios de prioridad ocurren precisamente porque nadie puede defender con datos por qué una épica merece más atención que otra.
What — Las journeys o features
El what responde a qué capacidades necesita el usuario para que se produzca el cambio deseado. Aquí es donde el User Story Mapping es especialmente útil: se mapean las actividades que realiza el usuario a lo largo de su experiencia, y se identifican las capacidades que el producto debe ofrecer en cada momento.
Para la épica de reactivación de GymTonic, las journeys principales eran:
- Detección y segmentación de socios inactivos
- Contacto personalizado con propuesta de reactivación
- Reserva de una sesión de reincorporación
- Seguimiento de la asistencia tras la reactivación
El mapa permite ver el producto completo de un vistazo, decidir qué es imprescindible para la primera versión y qué puede esperar, y asegurarse de que las historias mantienen coherencia entre sí.
How — Las historias de usuario
El how responde a cómo se materializa cada capacidad en incrementos que el equipo puede construir y entregar en un sprint. Las historias son el nivel de detalle donde se planifica, se estima y se ejecuta.
Una historia perteneciente a la journey de contacto personalizado en GymTonic:
"Como responsable de retención, cuando identifico a un socio que lleva más de 60 días sin visitar el gimnasio, quiero ver en su ficha el historial de actividades que más frecuentaba, para poder personalizar el mensaje de reactivación con algo concreto que le motive."
Esta historia especifica quién, cuándo, qué necesita y para qué lo usa. El equipo puede construirla. Y se puede medir si funciona.
Paso 1: Valida que la épica está lista para descomponerse
Una épica no está lista si no puede responder bien al Why. Antes de empezar a escribir historias, verifica:
- ¿Describe un problema o una solución? Si la épica dice "Crear un sistema de notificaciones push", es una solución. Si dice "Los socios inactivos no reciben comunicación personalizada que les motive a volver", es un problema. Solo los problemas bien definidos generan buenas historias.
- ¿Tiene una hipótesis explícita? ¿Qué crees que pasará si lo construyes? Sin hipótesis, no hay nada que validar — y sin validación, no hay aprendizaje.
- ¿Tiene métricas de éxito? Sin métricas, no sabrás si lo que construiste funcionó. Y sin eso, las decisiones de priorización son opinión, no evidencia.
- ¿Sabes quién sufre el problema? No "el socio" en abstracto, sino el socio que lleva entre 30 y 90 días sin venir, con contrato mensual activo, que en el pasado asistía a clases colectivas.
Si las respuestas son vagas, la épica necesita más trabajo antes de descomponerse. Invertir 1-2 semanas aquí ahorra semanas de retrabajo después.
En el artículo How to Succeed with Product Discovery and Validation explico cómo integrar este trabajo de descubrimiento dentro del ritmo de Scrum, y por qué los equipos que se saltan este paso acaban construyendo lo que nadie necesita.
Paso 2: Escribe historias que especifiquen un cambio de comportamiento
La mayoría de las historias que veo en los equipos describen funcionalidades, no cambios de comportamiento.
❌ Historia débil:
"Como socio, quiero recibir notificaciones para estar informado de las novedades del gimnasio."
¿Qué hace el socio de manera diferente gracias a esta historia? No lo sabemos. No hay forma de medir si cumplió su propósito.
✅ Historia con cambio de comportamiento:
"Como socio de GymTonic que lleva más de 45 días sin venir, cuando recibo un mensaje con una clase que frecuentaba antes, quiero poder reservar esa clase directamente desde el mensaje, para poder volver sin tener que recordar cómo funciona la app."
Una historia bien escrita responde siempre a estas cuatro preguntas:
- ¿Quién es exactamente? El rol concreto con su contexto, no "el usuario".
- ¿En qué situación? El momento o trigger en que aparece la necesidad.
- ¿Qué quiere poder hacer? La capacidad específica que necesita.
- ¿Para qué le sirve? El resultado esperado, observable y preferiblemente medible.
En ¿Cómo la IA aumenta el impacto del Product Owner? muestro ejemplos concretos de cómo usar IA para construir Story Maps y redactar historias con este nivel de especificidad.
Paso 3: Divide las historias para aprender, no solo para entregar
Cuando una historia es demasiado grande para completarse en un sprint, hay que dividirla. Pero el criterio con el que se divide importa tanto como la división en sí.
El objetivo de dividir no es solo hacer el trabajo más manejable. Es conseguir feedback extremo a extremo lo antes posible: que el usuario pueda interactuar con algo real, que el equipo pueda observar si la hipótesis se cumple, y que el Product Owner pueda decidir con información si merece la pena seguir invirtiendo en esa dirección. Una historia pequeña que llega al usuario real genera aprendizaje. Una historia grande que tarda tres sprints en completarse genera incertidumbre acumulada.
División horizontal — por capas técnicas — es el error más frecuente:
- Historia 1: diseño de la pantalla de reactivación
- Historia 2: desarrollo del backend de notificaciones
- Historia 3: integración con el sistema de reservas
Ninguna entrega valor ni genera aprendizaje por sí sola. El socio no puede usar el diseño sin el backend.
División vertical — por caso de uso o segmento — genera incrementos que el usuario puede usar y sobre los que el equipo puede aprender:
- Historia 1: el responsable de retención puede ver la lista de socios con más de 45 días de inactividad y enviarles un mensaje manual desde el panel → ¿Lo usa? ¿Genera visitas?
- Historia 2: el sistema detecta automáticamente socios inactivos y envía el mensaje sin intervención manual → ¿La automatización mejora la tasa de respuesta?
- Historia 3: el mensaje incluye una clase recomendada basada en el historial de asistencia → ¿La personalización aumenta las reservas?
Cada historia es también un experimento. Si la primera no genera visitas, tiene sentido cuestionar si la segunda y la tercera merecen construirse.
Algunas técnicas de división útiles:
- Por segmento de usuario: socios con 30 días de inactividad primero, con 90 días después.
- Por output simplificado: mensaje genérico primero, personalizado después.
- Por capacidad manual vs. automática: primero lo que hace el operador humano, luego lo que automatiza el sistema.
Paso 4: Define criterios de aceptación basados en comportamiento observable
Los criterios de aceptación son el contrato entre el Product Owner y el equipo. Un criterio útil describe qué debe ser verdad cuando la historia esté completa, no cómo está construida técnicamente.
El formato Given-When-Then mantiene ese foco:
- Given (dado que): el contexto o estado inicial
- When (cuando): la acción que realiza el usuario
- Then (entonces): el resultado observable
Ejemplo para GymTonic:
Given que soy responsable de retención y accedo al panel de socios inactivos, When filtro por socios con más de 45 días sin visita, Then veo la lista con nombre, días de inactividad y la última clase a la que asistieron, y puedo enviar un mensaje predefinido a cada uno con un solo clic.
Este criterio es verificable, evita ambigüedades y ayuda al equipo a saber exactamente cuándo la historia está terminada.
El trabajo de refinamiento es el momento natural para construir estos criterios con todo el equipo. En ¿Cómo triunfar con el Product Discovery? explico cómo integrar la validación de hipótesis en el ritmo habitual de Scrum.
Los antipatrones más comunes
🔴 La épica sin hipótesis ni métricas. Una épica sin caso de negocio claro es una idea, no una iniciativa. Sin métricas previas, no hay forma de saber si lo que se construyó valió la pena — y sin eso, las prioridades cambian por impulso, no por evidencia.
🔴 El usuario genérico. "Como usuario quiero..." no dice nada. Cada historia necesita un rol concreto con contexto y situación.
🔴 La solución disfrazada de necesidad. "Como socio, quiero recibir una notificación push cuando lleve 30 días sin venir." Esto ya prescribe la solución. La necesidad es volver al gimnasio; la solución puede ser una notificación, una llamada, un descuento o cualquier otra cosa.
🔴 La división horizontal. Diseño, backend y frontend como historias separadas no generan aprendizaje ni entregan valor incremental.
🔴 Usar el formato de historia para todo. Un bug no es una historia. Una tarea de refactorización no es una historia. Forzar el formato donde no aplica genera ruido y confusión sobre qué es realmente prioritario.
🔴 La historia sin criterios de aceptación. Sin criterios, "terminado" significa cosas distintas para personas distintas.
El patrón del PO que acaba siendo un proxy entre negocio y desarrollo — sin acceso real al usuario ni capacidad para validar hipótesis — lo analizo en detalle en How Can OKRs Empower the Scrum Teams?, donde explico cómo los OKR pueden devolver al Product Owner su rol estratégico.
Un proceso mínimo para aplicar esta semana
- Elige una épica de tu backlog que lleve más de un sprint sin convertirse en historias.
- Escribe su Why: problema, hipótesis explícita y métricas de éxito.
- Identifica qué ítems de esa épica son realmente historias de usuario y cuáles son tareas técnicas o bugs — y trátalos de manera diferente.
- Mapea las journeys principales del usuario con un User Story Map básico.
- Para la primera journey, escribe 2-3 historias con cambio de comportamiento explícito.
- Verifica que cada historia tiene criterios de aceptación en formato Given-When-Then.
- Comprueba que las historias pueden completarse en un sprint y que generan feedback observable. Si no, aplica división vertical.
Para profundizar
Si quieres trabajar estos conceptos con tu equipo de manera práctica, los cursos certificados de Scrum.org son el camino más directo:
- Professional Scrum Product Owner (PSPO) — fundamentos sólidos de gestión de producto con Scrum: backlog, valor, historias y planificación incremental.
- Professional Scrum Product Owner - Advanced (PSPO-A) — técnicas avanzadas de descomposición de valor, toma de decisiones de producto y gestión del backlog en contextos complejos.
- Professional Scrum Product Owner™ (PSPO-AIE) — como amplificar la capacidad e impacto del Product Owner con Inteligencia Artificial. Nuevo curso.
Y si quieres seguir leyendo sobre los temas de este artículo, estos son mis artículos relacionados en Scrum.org:
- How to Integrate Scrum and UX with Dual-Track Scrum — cómo integrar discovery y delivery en el ritmo de Scrum
- How to Succeed with Product Discovery and Validation — cómo validar hipótesis antes de construir
- ¿Cómo triunfar con el Product Discovery? — versión en castellano del anterior, con ejemplos adicionales
- ¿Cómo la IA aumenta el impacto del Product Owner? — Story Maps e historias de usuario con ayuda de IA
- How Can OKRs Empower the Scrum Teams? — cómo los OKR conectan la épica con la estrategia y devuelven autonomía al equipo
¿Cómo lo estáis haciendo en tu equipo? ¿En qué punto se atasca más el paso de la épica a las historias? Comparte tu experiencia en los comentarios.