8 min lectura • Guide 787 of 877
Técnicas de División de User Stories
Las historias grandes son riesgosas y difíciles de estimar. GitScrum ayuda a los equipos a rastrear historias divididas mientras mantiene la conexión con el epic original.
Por Qué Dividir Historias
Beneficios de Historias Pequeñas
BENEFICIOS DE HISTORIAS PEQUEÑAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RIESGOS DE HISTORIA GRANDE: │
│ ─────────────────────────── │
│ ❌ Difícil de estimar con precisión │
│ ❌ Puede no caber en el sprint │
│ ❌ Ciclos de feedback largos │
│ ❌ Alto riesgo de retrabajo │
│ ❌ Progreso bloqueado │
│ ❌ Síndrome del "90% hecho" │
│ │
│ BENEFICIOS DE HISTORIA PEQUEÑA: │
│ ────────────────────────────── │
│ ✅ Más fácil de estimar │
│ ✅ Cabe en el sprint │
│ ✅ Feedback rápido │
│ ✅ Menor riesgo │
│ ✅ Progreso visible │
│ ✅ Hecho es hecho │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ GUÍA DE TAMAÑO: │
│ │
│ MUY GRANDE (13+ puntos): │
│ • Más de la mitad del sprint │
│ • División requerida │
│ │
│ LÍMITE (8 puntos): │
│ • Considerar dividir │
│ • Depende de la complejidad │
│ │
│ BUEN TAMAÑO (1-5 puntos): │
│ • Se puede completar en 1-3 días │
│ • Cabe bien en el sprint │
│ │
│ MUY PEQUEÑA (1 punto): │
│ • Overhead de tracking cuesta más que el trabajo │
│ • Combinar con trabajo relacionado │
└─────────────────────────────────────────────────────────────┘
Patrones de División
Por Pasos del Flujo de Trabajo
DIVIDIENDO POR FLUJO DE TRABAJO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATRÓN: Operaciones CRUD │
│ │
│ ORIGINAL (21 puntos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como admin, quiero gestionar usuarios para ││
│ │ controlar el acceso al sistema. ││
│ │ ││
│ │ Esto incluye: ││
│ │ • Crear usuarios ││
│ │ • Listar usuarios ││
│ │ • Editar usuarios ││
│ │ • Eliminar usuarios ││
│ │ • Asignar roles ││
│ │ • Buscar/filtrar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Ver lista de usuarios (3 pts) ││
│ │ Lista básica con nombre, email, estado ││
│ │ ││
│ │ 2. Crear nuevo usuario (5 pts) ││
│ │ Formulario con validación, notificación por email ││
│ │ ││
│ │ 3. Editar detalles de usuario (3 pts) ││
│ │ Actualizar nombre, email, estado ││
│ │ ││
│ │ 4. Eliminar/desactivar usuario (3 pts) ││
│ │ Soft delete con confirmación ││
│ │ ││
│ │ 5. Asignar roles a usuario (5 pts) ││
│ │ Selector de roles, display de permisos ││
│ │ ││
│ │ 6. Buscar y filtrar usuarios (3 pts) ││
│ │ Por nombre, email, rol, estado ││
│ │ ││
│ │ Total: 22 pts (en 6 historias más pequeñas) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Cada historia entrega valor independientemente │
│ Se puede entregar después de historia 1-2 │
└─────────────────────────────────────────────────────────────┘
Por Tipo de Usuario
DIVIDIENDO POR PERSONA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATRÓN: Diferentes Usuarios, Diferentes Necesidades │
│ │
│ ORIGINAL (13 puntos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como usuario, quiero un dashboard para ver ││
│ │ métricas relevantes y acciones. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROBLEMA: "Usuario" es muy genérico │
│ Diferentes usuarios necesitan diferentes cosas │
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Dashboard de admin (5 pts) ││
│ │ Como admin, quiero ver salud del sistema, ││
│ │ actividad de usuarios y aprobaciones pendientes. ││
│ │ ││
│ │ 2. Dashboard de manager (5 pts) ││
│ │ Como manager, quiero ver métricas del equipo, ││
│ │ progreso del sprint y capacidad. ││
│ │ ││
│ │ 3. Dashboard de desarrollador (3 pts) ││
│ │ Como desarrollador, quiero ver mis tareas ││
│ │ asignadas, actividad reciente y bloqueadores. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFICIO: Cada persona obtiene exactamente lo que necesita│
│ Se puede priorizar por importancia del usuario │
└─────────────────────────────────────────────────────────────┘
Por Happy Path + Casos Edge
DIVIDIENDO POR ESCENARIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATRÓN: Empezar Simple, Agregar Complejidad │
│ │
│ ORIGINAL (13 puntos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como cliente, quiero comprar items para ││
│ │ recibir productos. ││
│ │ ││
│ │ Incluye: ││
│ │ • Agregar al carrito ││
│ │ • Múltiples métodos de pago ││
│ │ • Códigos de descuento ││
│ │ • Manejo de pago fallido ││
│ │ • Reembolsos parciales ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HAPPY PATH (entregar primero): ││
│ │ 1. Checkout básico con tarjeta de crédito (5 pts) ││
│ │ Un item, un método de pago, ruta de éxito ││
│ │ ││
│ │ MEJORAS: ││
│ │ 2. Agregar códigos de descuento (3 pts) ││
│ │ Validar y aplicar descuento ││
│ │ ││
│ │ 3. Múltiples métodos de pago (3 pts) ││
│ │ Agregar PayPal, transferencia bancaria ││
│ │ ││
│ │ CASOS EDGE: ││
│ │ 4. Manejar fallos de pago (3 pts) ││
│ │ Lógica de reintento, mensajes de error ││
│ │ ││
│ │ 5. Procesar reembolsos (3 pts) ││
│ │ Reembolsos completos y parciales ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Se puede entregar después de historia 1 - checkout básico │
│ Cada historia adicional agrega capacidad │
└─────────────────────────────────────────────────────────────┘
Por Variaciones de Datos
DIVIDIENDO POR TIPO DE DATOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATRÓN: Diferentes Datos, Misma Feature │
│ │
│ ORIGINAL (13 puntos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como usuario, quiero exportar mis datos para ││
│ │ analizarlos en otras herramientas. ││
│ │ ││
│ │ Formatos: CSV, Excel, PDF, JSON ││
│ │ Datos: Órdenes, Usuarios, Productos, Analíticas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIR POR FORMATO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Exportar a CSV (3 pts) ││
│ │ 2. Exportar a Excel (3 pts) ││
│ │ 3. Exportar a PDF (5 pts) - más complejo ││
│ │ 4. Exportar a JSON (2 pts) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ O DIVIDIR POR TIPO DE DATOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Exportar órdenes (3 pts) ││
│ │ 2. Exportar usuarios (2 pts) ││
│ │ 3. Exportar productos (2 pts) ││
│ │ 4. Exportar analíticas (5 pts) - más complejo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EMPEZAR CON: │
│ Datos más valiosos + formato más común │
│ "Exportar órdenes a CSV" │
└─────────────────────────────────────────────────────────────┘
Manteniendo el Valor
Criterios INVEST
ASEGURANDO QUE LAS HISTORIAS DIVIDIDAS SEAN BUENAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CADA DIVISIÓN DEBE SEGUIR CUMPLIENDO INVEST: │
│ │
│ I - INDEPENDIENTE │
│ Puede desarrollarse sin otras historias │
│ (alguna dependencia OK, pero sin bloquear) │
│ │
│ N - NEGOCIABLE │
│ Detalles pueden discutirse con el equipo │
│ No sobre-especificada │
│ │
│ V - VALIOSA │
│ Entrega algo útil al usuario │
│ No solo trabajo técnico │
│ │
│ E - ESTIMABLE │
│ El equipo puede dimensionarla │
│ No muy vaga │
│ │
│ S - PEQUEÑA │
│ Cabe en un sprint │
│ Idealmente 1-5 puntos │
│ │
│ T - TESTEABLE │
│ Criterios de aceptación claros │
│ Se puede verificar que funciona │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EVITAR: │
│ ❌ Tareas técnicas ("Configurar base de datos") │
│ ❌ Cortes horizontales ("Construir capa de API") │
│ ❌ Capas ("Frontend para feature X") │
│ │
│ PREFERIR: │
│ ✅ Cortes verticales que entregan valor de usuario │
└─────────────────────────────────────────────────────────────┘