Cómo descomponer épicas en historias listas para el sprint

Equipo ágil frente a una pizarra separando una nota adhesiva grande en varias más pequeñas, representando el proceso de dividir una épica en historias de usuario manejablesEquipo ágil frente a una pizarra separando una nota adhesiva grande en varias más pequeñas, representando el proceso de dividir una épica en historias de usuario manejables Una épica en tu backlog no es trabajo. Es una promesa de que existe trabajo en algún lugar dentro de ella. Hasta que la descompongas en historias que tu equipo pueda estimar y entregar en un solo sprint, es solo un marcador de posición con ambición. La mayoría de los equipos lo saben. Donde se quedan atascados es en la división en sí. La épica se siente como una sola cosa grande, y cada intento de separarla produce piezas demasiado pequeñas para ser significativas o demasiado grandes para caber en un sprint. Esta guía cubre los patrones y técnicas que hacen que la división sea limpia.

Qué hace que una historia esté "lista para el sprint"

Una historia lista para el sprint cumple estos criterios:
  • Suficientemente pequeña para completarse en un sprint (idealmente 1-5 story points)
  • Entregable de forma independiente, lo que significa que no depende de que otras historias se terminen primero
  • Cortada verticalmente, entregando una porción delgada de funcionalidad de extremo a extremo, no solo una pieza del backend o solo la interfaz
  • Estimable por tu equipo en planning poker sin un debate de 15 minutos
  • Testeable con una condición clara de aprobado/fallido
Si ya conoces los criterios INVEST, es la misma idea. El objetivo son historias lo suficientemente concretas para poder construir a partir de ellas.

6 patrones para dividir épicas

No hay una única forma correcta de dividir una épica. Pero estos seis patrones cubren la mayoría de las situaciones. Pruébalos en orden. El primero que aplique generalmente produce las historias más limpias.

1. Dividir por paso del flujo de trabajo

La mayoría de las épicas describen un proceso con múltiples pasos. Cada paso puede convertirse en su propia historia. Épica: "Como cliente, quiero comprar un producto en línea."
HistoriaDescripción
Explorar productosEl cliente puede ver un catálogo de productos con filtros
Agregar al carritoEl cliente puede agregar artículos a un carrito de compras
Realizar pagoEl cliente puede ingresar datos de envío y pago
Confirmación de pedidoEl cliente recibe un correo de confirmación después de la compra
Cada historia tiene valor de forma independiente. Un cliente que puede explorar productos obtiene valor incluso antes de que exista el proceso de pago.

2. Dividir por regla de negocio

Cuando una épica tiene lógica con ramificaciones o múltiples reglas, cada regla es un punto de división natural. Épica: "Como usuario, quiero que el sistema calcule los costos de envío."
  • Envío gratuito para pedidos mayores a $50
  • Tarifa fija de $5 para envío estándar nacional
  • Tarifas en tiempo real del transportista para envío exprés
  • Envío internacional con estimación de aduanas
Comienza con la regla más simple (tarifa fija) y añade complejidad en sprints posteriores.

3. Dividir por tipo de usuario

Si diferentes usuarios interactúan con la misma funcionalidad de manera distinta, cada perspectiva es una historia. Épica: "Como usuario, quiero gestionar los miembros del equipo."
  • Como administrador, quiero invitar nuevos miembros por correo electrónico
  • Como administrador, quiero eliminar miembros del equipo
  • Como miembro, quiero ver quién está en mi equipo
  • Como propietario, quiero transferir la propiedad a otro administrador

4. Dividir por camino feliz vs. casos límite

Construye el caso directo primero. Maneja errores, casos límite y validaciones en historias posteriores. Épica: "Como usuario, quiero subir fotos de perfil."
  • Camino feliz: Subir un JPEG o PNG de menos de 5MB y verlo como mi avatar
  • Caso límite: Mostrar un error cuando el archivo es demasiado grande o tiene formato incorrecto
  • Caso límite: Recortar y redimensionar la imagen antes de guardarla
  • Caso límite: Eliminar o reemplazar una foto existente
Desarrollador mirando un diagrama en una pizarra que muestra una caja grande etiquetada como épica siendo dividida en cajas más pequeñas conectadas que representan historias de usuario, con flechas mostrando dependenciasDesarrollador mirando un diagrama en una pizarra que muestra una caja grande etiquetada como épica siendo dividida en cajas más pequeñas conectadas que representan historias de usuario, con flechas mostrando dependencias

5. Dividir por tipo de dato o plataforma

Si una funcionalidad aplica a múltiples tipos de datos, plataformas o integraciones, cada uno es una historia. Épica: "Como usuario, quiero exportar mis informes."
  • Exportar como CSV
  • Exportar como PDF
  • Exportar como Excel
  • Enviar una exportación programada por correo electrónico

6. Dividir por rendimiento o escala

Comienza con algo que funcione para el caso común. Optimiza después. Épica: "Como usuario, quiero buscar en todos los proyectos."
  • Buscar dentro del proyecto actual (consulta simple)
  • Buscar en todos los proyectos (requiere indexación)
  • Agregar filtros (rango de fechas, asignado, estado)
  • Sugerencias de autocompletado mientras escribes

Un ejemplo real: descomponer "notificaciones de usuario"

Así se ve esto en la práctica. Supongamos que tu backlog tiene esta épica: "Como usuario, quiero recibir notificaciones sobre actividad relevante para mí." Eso es enorme. Apliquemos los patrones: Primero, dividir por flujo de trabajo. Enviar vs. recibir vs. gestionar notificaciones son preocupaciones separadas. Luego dividir por canal. Correo electrónico, notificaciones dentro de la aplicación y notificaciones push son cada una su propia historia. Dentro de cada canal, dividir por regla de negocio. ¿Qué eventos disparan una notificación? Cada uno (mencionado en un comentario, asignado a una tarea, fecha límite acercándose) es una historia. Finalmente, elige el camino feliz. Comienza con "el usuario recibe una notificación dentro de la aplicación cuando se le asigna una tarea." Un canal, un disparador, listo. Añade correo electrónico, push, preferencias y opciones de resumen después. El resultado: en lugar de una épica estimada como "enorme" que permanece en el backlog durante tres sprints, obtienes 8-12 historias que pueden priorizarse, estimarse y entregarse de forma incremental.

La regla del corte vertical

El error de división más común es separar una épica por capa técnica: En cambio, corta verticalmente. Cada historia debe tocar las capas que sean necesarias para entregar una porción delgada de funcionalidad que alguien pueda realmente usar y probar. Un corte vertical para una funcionalidad de notificaciones podría ser: "Cuando a un usuario se le asigna una tarea, aparece una notificación dentro de la aplicación." Eso toca el backend (disparador del evento, registro de notificación), la API (endpoint para obtener notificaciones) y el frontend (insignia y lista de notificaciones). Es delgado, pero funciona de extremo a extremo. Diagrama mostrando la diferencia entre división horizontal por capa técnica y división vertical por funcionalidad orientada al usuario, con el enfoque vertical resaltado como el método correctoDiagrama mostrando la diferencia entre división horizontal por capa técnica y división vertical por funcionalidad orientada al usuario, con el enfoque vertical resaltado como el método correcto

Cuando las historias siguen siendo demasiado grandes

A veces divides una épica y las historias resultantes siguen siendo demasiado grandes. Algunas señales:
  • El equipo la estima en 13+ puntos
  • Tiene más de 5 criterios de aceptación
  • La descripción usa la palabra "y" para conectar dos comportamientos diferentes
  • Múltiples miembros del equipo necesitarían trabajar en ella simultáneamente
Si eso ocurre, aplica los mismos patrones de nuevo. Una historia sobre "el usuario puede realizar el pago con envío y pago" se divide en "el usuario puede ingresar la dirección de envío" y "el usuario puede ingresar los datos de pago." Sigue dividiendo hasta que cada pieza quepa cómodamente en un sprint.

Usando herramientas para acelerar la división

Descomponer épicas es una habilidad que mejora con la práctica, pero las herramientas pueden acelerar el proceso. El Story Splitter de Kollabe toma la descripción de una épica y genera historias listas para el sprint usando los patrones anteriores. Es un buen punto de partida cuando estás mirando una épica grande y no sabes por dónde cortar. Una vez que tengas tus historias, el Generador de Historias de Usuario puede ayudarte a completarlas con criterios de aceptación adecuados y el formato estándar de historias de usuario. Luego llévalas a planning poker para estimar y validar que las divisiones realmente tengan sentido para tu equipo.

Una lista de verificación rápida antes del Sprint Planning

Revisa esto antes de incluir cualquier historia dividida en un sprint:

Cada historia entrega valor que un usuario puede ver o con el que puede interactuar

Ninguna historia depende de otra historia sin terminar en el mismo sprint

El equipo puede estimar cada historia sin debate prolongado

Los criterios de aceptación están definidos para cada historia

Las historias están cortadas verticalmente, no divididas por capa técnica

El alcance completo de la épica original está cubierto entre todas las historias

Si los seis puntos se cumplen, tus historias están listas para el Sprint Planning.

Comienza a dividir

Seis patrones, una regla: cada historia debe entregar un corte vertical de valor que quepa en un sprint. Cuando estés atascado mirando una épica vaga, elige el primer patrón que aplique, haz el corte y valida con estimación. Si las estimaciones siguen dispersas, corta de nuevo.

Suficientemente pequeña para terminarse en un sprint, idealmente estimada en 1-5 story points. Si tu equipo consistentemente termina historias en 1-3 días, vas por buen camino. Las historias que toman todo el sprint son riesgosas porque no dejan margen para imprevistos.

Está bien. Una épica con 15-20 historias simplemente significa que tienes una hoja de ruta clara para la entrega. Prioriza sin piedad. No tienes que construirlas todas. El product owner elige las historias de mayor valor para cada sprint.

Durante el refinamiento del backlog. El Sprint Planning es demasiado tarde porque necesitas historias ya refinadas y estimadas antes de esa reunión. La mayoría de los equipos dividen épicas 1-2 sprints antes de cuando planean trabajar en ellas.

Juega planning poker. Si el equipo puede estimar cada historia rápidamente y las estimaciones se agrupan de forma ajustada (un 3, un 5 y un 5 en vez de un 2 y un 13), la división está funcionando. Dispersiones amplias en la estimación significan que la historia todavía es demasiado vaga o demasiado grande.
Última actualización el 10/02/2026