Cómo dividir historias de usuario en serio (sin dibujos de autos)

El problema real con las historias grandes

Hay una imagen que generalmente representa agilidad y casi todos la hemos visto

La de creación de un auto:

• Primero un skate

• segundo un monopatín

• Tercero una bici

• Cuarto una motocicleta

• Quinto un automóvil (“Objetivo”)

En la realidad nadie trabaja así, ya que en las organizaciones y equipos, lo que ves son:

• Historias robustas

• Refinamientos difíciles

• Dependencias entre equipos

• QA comienza al final del sprint lo correspondiente al sprint

• El PO mete cosas a mitad del sprint porque es “importante”

Y cuando llega el momento de dividir en historias, empiezan los problemas, porque existe el temor de que se rompa todo, o que áreas externas no puedan entender nuestras entregas, en este punto ni mencionar entrega de valor, digámosle solo “avances”

Aquí empieza el caos: Porque dividir historias parece fácil… hasta que lo tienes que hacer y funcione en verdad

Voy a partir de un caso real, de los que pasan en equipos de verdad, para ver cómo se plantea el problema y cómo abordarlo correctamente.

A partir de ahí, entraré en formas concretas de dividir historias de usuario, basadas en lo que se suele ver en libros, artículos o incluso en referencias como Agile for All: https://agileforall.com/wp-content/uploads/2013/06/Story-Splitting-Flowchart-ES.pdf

Lo que generalmente nos pasa: Cuando la épica entrega valor… pero las historias no

Voy a poner un caso que es más común de lo que parece.

Tienes una épica que sí tiene sentido:

“Permitir a los usuarios contratar un seguro online”

Perfecto.

Apunta a valor real.

El cliente lo necesita.

Hasta aquí, todo bien.

Pero cuando bajas a historias de usuario, pasa esto:

• Historia 1 → Backend

• Historia 2 → Frontend

• Historia 3 → QA

• Historia 4 → Ajustes de arquitectura

Cada historia por separado:

• NO entrega valor

• NO se puede probar completa

• NO tiene sentido para el usuario

Pero cuando juntas todas…

• Recién funciona

• Recién se puede probar y subir a producción

ENTONCES ¿Cuál es el problema en sí?

Desde ya tengamos en cuenta de donde partimos:

“No estás dividiendo por valor. Estás dividiendo por fases técnicas.”

Me refiero a que el backlog que estamos manejando en realidad es un MINI-CASCADA dentro del sprint.

Secuencia real:

1. backend

2. frontend

3. QA

4. integración

5. recién ahí hay valor

Esto rompe todo:

• QA siempre al final

• historias “terminadas” que no sirven

• bloqueos constantes

• sensación de avance falsa

• sprint que “cumple puntos” pero no entrega nada

Como una “red flag” que no andamos bien:

Si una historia necesita otras 3 para tener sentido…

NO es una historia, sino que una parte técnica

¿Cómo lo dividirla mejor?

Tomo el mismo ejemplo para poder comparar luego.

Si antes lo hemos hecho así:

Épica: contratar seguro

Historias:

• crear API de contratación

• hacer pantalla de contratación

• integrar validaciones

• hacer pruebas

y el valor se tarde, al final de acabar la épica.

La forma “correcta”:

Ahora lo haremos donde cada historia entregue valor real.

1RA HISTORIA:

Como usuario quiero simular una contratación básica

Incluye:

• mínimo backend

• mínimo frontend

• flujo completo

• testable

Ya puedes probar algo!

Puedes enseñarlo!

y sobre todo ya puedes aprender!

---

2DA HISTORIA:

Como usuario quiero validar mis datos antes de contratar

Añade reglas de negocio

---

3RA HISTORIA:

Como usuario quiero confirmar la contratación

Completa el flujo

---

4TA HISTORIA:

Como usuario quiero ver mensajes de error claros

Mejora la experiencia

---

Qué cambió realmente

No cambiaste la funcionalidad.

Cambiaste esto:

DE DIVIDIR POR TECNOLOGÍA A DIVIDIR POR VALOR ENTREGABLE.

Cada historia ahora:

• Podemos probarla

• Son demostrables

• Podemos desplegar

• Ya tiene sentido por sí sola

¿Por qué no hacen esto todas las organizaciones si no estamos descubriendo la pólvora?

Es que Lo difícil de este cambio no es técnico, es mental.

Ya que implica:

• Que dejes de pensar en tareas

• Dejar de repartir trabajo por roles y aquí chocas con la organización, no solo a visión de equipo.

• Que dejes de optimizar por especialidad

Lo bonito será cuando ya los equipos y líderes piensen en:

¿QUÉ PUEDO PONER EN PRODUCCIÓN ANTES?

En este artículo elegí iniciar con los ejemplos y casos reales, de aquí ya sigue un poco de definición que también sirve para diferentes casos o también para un mismo caso quizás que lo quieras abordar diferente.

Qué significa realmente dividir una historia

Aquí es donde suele empezar el error.

Dividir una historia no es repartir trabajo.

No es esto:

• backend por un lado

• frontend por otro

• base de datos aparte

Eso no son historias. Eso es cómo está organizado el equipo.

Dividir una historia es otra cosa: Es dividir el valor que recibe el usuario

Un ejemplo para que se entienda mejor:

Historia original: "Como usuario quiero iniciar sesión"

División típica (lo que no se debe hacer pero es lo que vemos a diario):

• Desarrollar endpoint

• Elaborar pantalla

• Conectar BBDD

Eso no sirve de nada por separado.

División que si entrega valor:

• Login básico

• Login con validaciones

• Login con recuperación de contraseña

Aquí cada historia ya tiene sentido!

No es excelente, pero ya se puede usar. Ahí la diferencia.

Regla simple para dividir historias

La idea no es complicarnos ni tampoco memorizar ni generarnos mas problemas de los que ya vivimos en nuestras organizaciones, solo quedemonos con lo siguiente:

Una historia bien dividida se puede entregar sola

Se puede probar sola y tiene sentido así solita.

Si necesitas juntar varias historias para que funcione… pues no está bien dividida.

No hvoy a hablar de INVEST ni de esas teorías que me hacen acordar a excesiva información en algunos cursos de la universidad.

Solo quisiera que te quedes con esto:

¿Tiene sentido si lo pongo en producción así como está?

Si la respuesta es NO, toca seguir revisando.

Forma 1 — Dividir por workflow (lo más natural)

Esta es la forma más intuitiva.

Ejemplo: Como usuario quiero comprar un producto

Lo normal es dividir por pasos:

• buscar producto

• ver detalle

• añadir al carrito

• pagar

• confirmar

Aquí viene algo importante que muchos equipos no hacen.

Puedes dividir de dos formas:

Por pasos (lo típico)

Cada parte del flujo es una historia.

Por versión completa pero simple

En lugar de hacer todo por partes, haces una primera versión completa pero básica:

• compra simple sin validaciones

• luego mejoras

• luego control de errores

• luego optimización

Esta segunda forma suele funcionar mejor en equipos reales, porque permite probar antes y aprender antes.

Forma 2 — Dividir por reglas de negocio

Esto aparece mucho cuando una historia parece simple… pero no lo es.

Ejemplo: Calcular descuentos

Cuando empiezas a mirar, resulta que hay:

• descuento fijo

• Descuento por volumen

• Descuento por tipo de cliente

• Descuento por fechas

Difícil que en una sola historia se haga.

Entonces: Dividir por reglas te permite avanzar sin bloquearte.

Primero lo básico, luego lo complejo.

---

Forma 3 — Dividir por versión simple primero

Esto es clave cuando todo parece grande.

Ejemplo: Exportar reportes

En lugar de hacerlo todo de golpe:

• Exportar CSV

• Luego al Excel

• Luego por PDF

• Luego filtros

Primero haces algo que funcione, luego vamos mejorandolo.

Esto evita el típico problema de:

Es que llevamos días trabajando y aún no se puede probar nada

---

Forma 4 — Dividir por datos

Muy útil cuando todo empieza a crecer sin control.

Ejemplo: Mostrar estadísticas

Lo dividimos en:

• Solo ventas

• Ventas + usuarios

• Ventas + ingresos

Así no hacemos todo desde el inicio.

---

Forma 5 — Dividir por riesgo (cuando no tienes ni idea por dónde empezar)

Hay casos donde simplemente no entiendes bien lo que hay que hacer.

Integraciones externas, sistemas nuevos, cosas raras…

Aquí forzar una historia es peor.

• Hacemos un spike

• Reducimos incertidumbre

Ya luego lo dividimos.

Este caso es de los que mas pasan aunque nadie lo reconozca o no lo vea como buena práctica.

Errores típicos al dividir historias

Sinceramente es lo que mas he visto, seguro muchos de nosotros también en los diferentes equipos:

• Dividir por frontend / backend

• Dividir por tareas

• Dividir por roles técnicos

• Historias que no entregan nada

• Historias que dependen de otras

• Historias demasiado grandes

• Meter todo en una sola

Y uno muy importante:

• Empezar por lo más complejo

Esto suele pasar sin darse cuenta.

Y es lo que rompe el sprint desde el principio.

---

Cómo usar esto en un refinamiento real

Lo que podemos hacer en nuestros equipos:

1. Leer la historia, de preferencia leela antes de la ceremonia.

2. Preguntar: ¿esto cabe en un sprint? Esto ya durante el refinamiento.

3. Si no → dividir

4. Buscar si hay un flujo

5. Ver si hay versión simple

6. Separar reglas de negocio

7. Separar datos si aplica

8. Si hay dudas aplicamos spike , sin miedo por así decir.

9. Preguntar: ¿esto se puede entregar solo?

10. Esto como bucle volvemos al paso 1 historia por historia, refinamiento tras refinamiento, así hasta que el equipo también se adapte. De ese modo haremos que el equipo también pueda tener este pensamiento.

Lo importante de este artículo es que tengamos la consciencia que si no llegamos a aprender a dividir historias, vamos a tener un altiismo riesgo de que los sprints se rompan, los refinamientos se alarguen, las palnificaciones fallen y de ahi digan que agilidad no funciona, que el QA no pueda avanzar hasta después de mitad de sprint, que el PO siga metiendo cosas a mitad de sprint o cuando le plazca. Todo esto que digo a la final nos hace perder foco.

Te pido que no lo veas como que Dividir historias es solo un detalle técnico, porque NO lo es...

Es una habilidad clave para que el equipo funcione!

Como al inicio del articulo, Esto NO va de patrones, va de deciciones:

• Qué hacemos primero

• Qué nos aporta valor antes

• Qué reduce riesgo

• Qué desbloquea al equipo

Por eso dos equipos pueden dividir la misma historia… y hacerlo completamente diferente y ambos pueden estar bien!

Gracias a todos los que llegaron hasta el final. Si tienen alguna sugerencia de lagún tópico que tocar, pueden dejarmelo como sugerencia aquí abajo.