6 min lectura • Guide 192 of 877
Mejorando Precisión de Sprint Planning
La precisión del sprint planning determina si entregas lo que comprometiste o constantemente fallas en los objetivos. Planning preciso construye confianza con stakeholders, habilita forecasting confiable y crea ritmo sostenible. Requiere datos, disciplina y calibración continua.
Problemas de Precisión de Planning
| Problema | Causa | Solución |
|---|---|---|
| Sobre-compromiso | Sesgo de optimismo | Usar velocity histórico |
| Trabajo sin terminar | Scope creep | Proteger compromiso |
| Sorpresas constantes | Trabajo desconocido | Añadir buffer |
| Estimaciones imprecisas | Sin feedback loop | Trackear actual vs estimado |
Mejora de Estimación
Usando Datos Históricos
PLANNING BASADO EN VELOCITY
═══════════════════════════
VELOCITY HISTÓRICO:
─────────────────────────────────────
Sprint Comprometido Completado Tasa
────────────────────────────────────
20 35 32 91%
21 38 29 76%
22 32 30 94%
23 34 33 97%
24 36 31 86%
25 33 32 97%
─────────────────────────────────────
Velocity promedio: 31 puntos
Desviación estándar: 1.5 puntos
Capacidad confiable: 30 puntos (prom - 1 std)
PLANNING PRÓXIMO SPRINT:
├── No comprometer >30 puntos
├── Si items inciertos, comprometer menos
├── Dejar espacio para sorpresas
└── 30 puntos = compromiso realista
TENDENCIA DE VELOCITY:
├── Estable: Usar promedio
├── Mejorando: Usar promedio reciente (últimos 3)
├── Declinando: Investigar causa raíz
└── Errático: Usar el más bajo reciente
Descomposición de Tareas
DIVIDIENDO EL TRABAJO
═════════════════════
ANTES:
─────────────────────────────────────
User Story: "Login de usuario"
Estimación: 13 puntos (grande, vaga)
Precisión: Pobre (muy grande para estimar)
DESPUÉS (descompuesta):
─────────────────────────────────────
Sub-tarea 1: UI de formulario login (2 pts)
Sub-tarea 2: Endpoint de autenticación (3 pts)
Sub-tarea 3: Gestión de sesión (2 pts)
Sub-tarea 4: Manejo de errores (2 pts)
Sub-tarea 5: Tests unitarios (2 pts)
Sub-tarea 6: Tests de integración (2 pts)
─────────────────────────────────────
Total: 13 puntos (mismo, pero más preciso)
POR QUÉ ESTO FUNCIONA:
├── Tareas pequeñas son más fáciles de estimar
├── Dependencias se hacen visibles
├── Progreso es más trackeable
├── Trabajo paralelo posible
└── Menos sorpresas ocultas
Gestión de Capacidad
Calculando Capacidad Real
FÓRMULA DE CAPACIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAPACIDAD BRUTA: │
│ 5 desarrolladores × 10 días × 6 horas productivas │
│ = 300 horas disponibles │
│ │
│ DEDUCCIONES: │
│ • Reuniones: 15% (45 horas) │
│ • Vacaciones/Enfermedades: 10% (30 horas) │
│ • Trabajo no planificado: 10% (30 horas) │
│ • Soporte/Mantenimiento: 10% (30 horas) │
│ ───────────────────────────────────────── │
│ Total deducciones: 45% (135 horas) │
│ │
│ CAPACIDAD NETA: 300 - 135 = 165 horas │
│ │
│ CAPACIDAD EN PUNTOS: │
│ Si 1 punto ≈ 4 horas de trabajo │
│ Capacidad = 165 / 4 ≈ 41 puntos │
│ │
│ BUFFER DE SEGURIDAD (20%): │
│ Capacidad de planning = 41 × 0.8 = 33 puntos │
│ │
└─────────────────────────────────────────────────────────────┘
Factores que Afectan Capacidad
VARIACIONES DE CAPACIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REDUCIR CAPACIDAD CUANDO: │
│ • Sprint con días festivos │
│ • Vacaciones de miembros del equipo │
│ • Nuevo miembro del equipo (onboarding) │
│ • Migración/upgrade planeado │
│ • Sprint review importante (más prep) │
│ • Final de quarter (más reuniones) │
│ │
│ MANTENER CAPACIDAD ESTABLE CUANDO: │
│ • Equipo sin cambios │
│ • Trabajo familiar │
│ • Sin eventos especiales │
│ │
│ NUNCA AUMENTAR CAPACIDAD POR: │
│ • Presión de stakeholders │
│ • "Vamos a esforzarnos más" │
│ • Overtime esperado │
│ │
└─────────────────────────────────────────────────────────────┘
Protección del Scope
Política de Cambios Mid-Sprint
POLÍTICA DE CAMBIOS DURANTE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGLA: Scope comprometido está protegido │
│ │
│ SI LLEGA NUEVO TRABAJO: │
│ 1. ¿Es verdaderamente urgente? (caída de producción, etc.) │
│ 2. Si sí: Sacar algo de igual tamaño del sprint │
│ 3. Si no: Va al backlog para próximo sprint │
│ │
│ TRADE-OFF OBLIGATORIO: │
│ Nuevo item de 5 pts entra → 5 pts salen │
│ No hay magia, capacidad es finita │
│ │
│ EXCEPCIÓN: │
│ Solo incidentes de producción P1 │
│ Documentar el impacto en sprint │
│ │
│ BENEFICIO: │
│ • Stakeholders piensan antes de pedir │
│ • Equipo puede enfocarse │
│ • Compromisos son significativos │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas de Planning
MÉTRICAS DE PRECISIÓN DE PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TASA DE COMPLETACIÓN: │
│ % de stories comprometidas que se completan │
│ Objetivo: 80-90% │
│ │
│ VELOCITY VARIANCE: │
│ Qué tan estable es el velocity entre sprints │
│ Objetivo: <20% desviación │
│ │
│ SCOPE CREEP RATE: │
│ % de trabajo añadido mid-sprint │
│ Objetivo: <10% │
│ │
│ ESTIMACIÓN ACCURACY: │
│ Comparar estimado vs actual por historia │
│ Objetivo: Dentro de ±30% │
│ │
│ CARRY-OVER RATE: │
│ % de stories que pasan al siguiente sprint │
│ Objetivo: <15% │
│ │
│ DASHBOARD: │
│ Sprint 25: ✓ 88% completado | Creep: 8% | Carry: 12% │
│ Sprint 26: ✓ 91% completado | Creep: 5% | Carry: 9% │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Usar velocity histórico no deseos
- Descomponer trabajo grande en piezas <5 pts
- Contabilizar overhead realísticamente
- Incluir buffer para sorpresas
- Proteger el compromiso del scope creep
- Trackear y calibrar continuamente
- Retrospectiva de planning cuando falla el sprint