En la mayoría de equipos, el cuello de botella no está en la ejecución sino en cómo entra el trabajo al sprint. Una épica de tres meses no se puede empezar el lunes; necesita ser descompuesta en piezas que un equipo pueda terminar en días, validar y aprender. Descomponer bien es un acto de claridad, no de burocracia.
Lo curioso es que casi nadie lo enseña. Lo das por hecho cuando llevas años, pero cuando un equipo nuevo empieza, se nota: backlogs llenos de épicas-disfrazadas-de-historias, sprints que se desbordan, dependencias que aparecen el día del review.
01 · El porquéPor qué descomponer no es opcional.
Cuando un equipo trabaja con épicas sin descomponer, lo que ocurre es predecible: se asignan tareas grandes, se subestima el riesgo, las dependencias salen tarde y la previsibilidad del roadmap se desploma. La descomposición no es una formalidad de Scrum, es el mecanismo que convierte intención en flujo.
Y lo más importante: una épica descompuesta es una épica conversada. Forzar la descomposición obliga a hacer las preguntas que de otra forma se posponen — qué pasa si esto falla, qué hacemos si el usuario no tiene permisos, cómo lo medimos.
Si una épica no se puede descomponer en historias accionables, casi siempre es porque todavía no la entiendes lo suficiente para construirla.— Mike Cohn, parafraseado
02 · Marco mentalLos cuatro niveles de granularidad.
Antes de elegir técnica, conviene fijar el vocabulario. En la práctica trabajamos con cuatro niveles. No es ortodoxia: es lo que permite hablar sin malentendidos entre producto, ingeniería y negocio.
La regla práctica: si no puedes contar lo que pasa con una historia en una frase de usuario ("como X quiero Y para Z"), todavía es una épica. Y si necesitas más de tres frases para explicar una iniciativa, probablemente son dos.
03 · TécnicasSeis técnicas de split que sí funcionan.
Hay decenas de patrones publicados. Estas seis cubren el 90% de los casos que vemos en equipos de producto digital:
- Por workflow. Camino feliz primero, casos alternativos después. Casi siempre el mejor punto de partida.
- Por reglas de negocio. Una historia por cada regla independiente. Útil cuando hay lógica compleja.
- Por interfaz. Una historia por canal o dispositivo (web, móvil, API).
- Por dato. Variantes según tipo de input o tipo de usuario.
- Por operación CRUD. Crear primero, editar y borrar después. Funciona bien con CRUDs reales, mal con flujos.
- Por aplazamiento de rendimiento/escala. Versión funcional primero, optimización después.
El error más común es elegir la técnica que mejor encaja con la arquitectura técnica en lugar de la que mejor entrega valor al usuario. Si una historia no se puede demostrar a alguien que no es ingeniero, probablemente está mal partida.
Ejemplo aplicado: checkout de e-commerce.
Imagina la épica "Permitir checkout con varios métodos de pago". Aplicando split por workflow + por regla de negocio queda algo así:
// Épica original Épica: Checkout con múltiples métodos de pago // Descomposición H1 → Checkout con tarjeta (camino feliz, sin descuentos) H2 → Checkout con tarjeta + cupón válido H3 → Manejo de tarjeta rechazada (errores 4xx) H4 → Checkout con PayPal (sin cupón) H5 → Checkout con Bizum (sin cupón) H6 → Reglas de límite por método (ej. PayPal > 500€)
04 · ValidaciónEl test INVEST como filtro final.
Antes de meter una historia al sprint, pasa el filtro INVEST. Si falla en alguno de los criterios, todavía hay trabajo de descomposición pendiente:
- Independent — se puede entregar sin esperar a otra historia.
- Negotiable — no es un contrato cerrado, admite conversación.
- Valuable — alguien (usuario o stakeholder) reconoce el valor.
- Estimable — el equipo puede dar una talla con confianza.
- Small — cabe en un sprint con margen para imprevistos.
- Testable — hay criterios de aceptación verificables.
05 · Anti-patronesTres errores que vemos cada semana.
De diagnosticar backlogs ajenos sacamos los mismos tres patrones rotos:
Historias técnicas disfrazadas de valor.
"Como sistema, necesito una API REST..." no es una historia de usuario. Es una tarea técnica disfrazada. No hay nada de malo en tener tareas técnicas, pero no las llames historias — pierdes la conversación de valor.
Historias del tamaño del sprint completo.
Si una historia ocupa un sprint entero, has perdido toda la flexibilidad. Lo correcto: ninguna historia debería ocupar más del 30-40% de la capacidad de un sprint. Si ocurre, parte.
Acoplamiento invisible.
Dos historias "independientes" que en realidad necesitan la misma migración de schema. Si descubres esto en el sprint, es tarde. La detección temprana es uno de los beneficios secundarios de descomponer bien.
06 · ChecklistTu chuleta para el próximo refinement.
Si quieres llevar este artículo al refinement de mañana, ésta es la versión de bolsillo:
- ¿Esta historia cabe en un solo sprint, con margen?
- ¿La puedo demostrar a un no-ingeniero al final?
- ¿Tiene una sola unidad de valor reconocible?
- ¿Pasa el test INVEST entero?
- ¿He elegido una técnica de split por valor, no por arquitectura?
- ¿He hecho explícitas las dependencias con otras historias?
Si respondes sí a las seis, métela al sprint con confianza. Si fallas en una, vuelve a la pizarra — vale más una hora más de descomposición que dos semanas de sprint torcido.