7 min lectura • Guide 121 of 877
Creando Sprint Backlogs Efectivos
Un sprint backlog demasiado ambicioso lleva al fracaso y desmoralización. Uno que es muy ligero desperdicia capacidad. Crear sprint backlogs efectivos significa seleccionar la cantidad correcta del trabajo correcto, apropiadamente preparado y entendido por el equipo.
Problemas del Sprint Backlog
| Problema | Impacto | Solución |
|---|---|---|
| Sobre-compromiso | Sprint fallido, desmoralización | Usar datos de velocidad |
| Trabajo poco claro | Confusión mid-sprint | Refinamiento apropiado |
| Items muy grandes | Nunca terminar | Dividir tareas |
| Dependencias ocultas | Trabajo bloqueado | Mapeo de dependencias |
| Sin prioridades | Trabajo equivocado primero | Ordenamiento claro |
Preparación del Backlog
Definition of Ready
DEFINITION OF READY (DoR)
═════════════════════════
Una tarea está LISTA para sprint cuando:
CLARIDAD:
- [ ] Descripción clara y completa
- [ ] Criterios de aceptación definidos
- [ ] "Por qué" está entendido (contexto/valor)
- [ ] Preguntas han sido respondidas
TAMAÑO:
- [ ] Estimado por el equipo
- [ ] Puede completarse dentro del sprint
- [ ] Idealmente 1-3 días de trabajo
- [ ] Items más grandes están divididos
DEPENDENCIAS:
- [ ] Sin dependencias bloqueantes
- [ ] Dependencias externas identificadas
- [ ] Prerrequisitos completos o programados
RECURSOS:
- [ ] Diseño/mockups disponibles (si es necesario)
- [ ] Specs de API disponibles (si es necesario)
- [ ] Datos de test/entornos listos
- [ ] Skills existen en el equipo
Listo vs No Listo
LISTO VS NO LISTO
═════════════════
✓ LISTO:
"Implementar flujo de reset de password"
- Endpoint de API documentado
- Template de email aprobado
- Criterios de aceptación: 5 items específicos
- Estimación: 5 puntos
- Sin bloqueadores
✗ NO LISTO:
"Construir autenticación de usuario"
- Demasiado vago - ¿qué método de auth?
- Sin specs de API
- Sin criterios de aceptación
- Sin estimación
- Depende de trabajo no terminado
Proceso de Sprint Planning
Cálculo de Capacidad
CÁLCULO DE CAPACIDAD
════════════════════
PASO 1: Calcular Días Disponibles
─────────────────────────────────────
Duración del sprint: 10 días (2 semanas)
Miembros del equipo: 5 desarrolladores
Total persona-días: 50 días
PASO 2: Restar Indisponibilidad
─────────────────────────────────────
PTO: -3 días (@sarah, @mike)
Feriados: -0 días
Capacitación: -2 días (@lisa)
────────────────────────────
Disponible: 45 persona-días
PASO 3: Considerar No-Coding
─────────────────────────────────────
Reuniones (~15%): -6.75 días
Soporte/bugs (~10%): -4.5 días
────────────────────────────
Capacidad: 33.75 días
PASO 4: Convertir a Story Points
─────────────────────────────────────
Si 1 punto ≈ 0.5 día de trabajo ideal
Capacidad ≈ 67 story points
PASO 5: Aplicar Factor Histórico
─────────────────────────────────────
Velocidad promedio: 52 puntos
Últimos 3 sprints: 48, 55, 53
→ Objetivo este sprint: 50-55 puntos
(conservador dado PTO)
Reunión de Sprint Planning
ESTRUCTURA DE SPRINT PLANNING
═════════════════════════════
DURACIÓN: 2-4 horas (para sprint de 2 semanas)
PARTE 1: QUÉ (60 min)
─────────────────────────────────────
Product owner presenta:
├── Objetivo del sprint
├── Top prioridades del backlog
└── Contexto de negocio
Equipo confirma:
├── Entendimiento del trabajo
├── Preguntas respondidas
└── Trabajo está "listo"
PARTE 2: CUÁNTO (45 min)
─────────────────────────────────────
Calcular capacidad:
├── Disponibilidad del equipo
├── Compromisos conocidos
└── Buffer para incógnitas
Extraer del backlog:
├── Prioridad más alta primero
├── Hasta alcanzar capacidad
└── Dejar 10-15% buffer
PARTE 3: CÓMO (45+ min)
─────────────────────────────────────
Para cada item:
├── Dividir en subtareas
├── Identificar dependencias
├── Asignar owners iniciales
└── Notar riesgos/preocupaciones
OUTPUT:
├── Sprint backlog comprometido
├── Objetivo de sprint claro
├── Asignaciones iniciales de tareas
└── Riesgos documentados
Estructura del Backlog en GitScrum
Vista del Sprint Backlog
VISTA DEL SPRINT BACKLOG
════════════════════════
┌─────────────────────────────────────────────────────────┐
│ Sprint 23: Autenticación de Usuario │
│ Mar 18-29 | Meta: Completar flujo auth para móvil │
├─────────────────────────────────────────────────────────┤
│ Capacidad: 52 pts | Comprometido: 48 pts | Buffer: 8%│
├─────────────────────────────────────────────────────────┤
│ │
│ TODO (32 pts) IN PROGRESS DONE │
│ ──────────── ─────────── ──── │
│ │
│ ┌────────────────┐ ┌──────────┐ │
│ │ Login API │ │ Password │ │
│ │ 8 pts @mike │ │ reset │ │
│ │ Ready ✓ │ │ 5 pts │ │
│ └────────────────┘ │ @sarah │ │
│ └──────────┘ │
│ ┌────────────────┐ │
│ │ Setup OAuth │ │
│ │ 5 pts @lisa │ │
│ │ Ready ✓ │ │
│ └────────────────┘ │
│ │
│ ┌────────────────┐ │
│ │ Mobile login UI│ │
│ │ 8 pts @tom │ │
│ │ Bloqueado: API │ │
│ └────────────────┘ │
│ │
│ ... más items ... │
│ │
└─────────────────────────────────────────────────────────┘
División de Tareas
EJEMPLO DE DIVISIÓN DE TAREAS
═════════════════════════════
STORY: Implementación de Login API (8 pts)
SUBTAREAS:
├── Crear endpoint de login (2 pts)
│ └── @mike, Día 1-2
├── Implementar generación JWT (2 pts)
│ └── @mike, Día 2-3
├── Agregar rate limiting (1 pt)
│ └── @mike, Día 3
├── Escribir unit tests (2 pts)
│ └── @mike, Día 4
└── Actualizar documentación API (1 pt)
└── @mike, Día 4-5
DEPENDENCIAS:
├── Necesita: User model (completo ✓)
├── Necesita: Librería JWT (completo ✓)
└── Bloquea: Mobile login UI
CRITERIOS DE ACEPTACIÓN:
├── POST /api/login acepta email/password
├── Retorna JWT en éxito
├── Retorna 401 en credenciales inválidas
├── Rate limited a 5 intentos/minuto
├── Logged en audit trail
└── Tests cubren todos los escenarios
Gestionando el Sprint Backlog
Durante el Sprint
GESTIÓN DEL SPRINT BACKLOG
══════════════════════════
CHEQUEOS DIARIOS:
├── ¿Algún item bloqueado?
├── ¿Items tomando más de lo esperado?
├── ¿Hay scope creep?
├── ¿Todavía en camino para objetivo del sprint?
AJUSTES MID-SPRINT:
├── ¿Podemos atacar bloqueadores en equipo?
├── ¿Necesitamos cortar scope?
├── ¿Podemos agregar trabajo si vamos adelante?
└── Comunicar cambios
CAMBIOS DE SCOPE:
Si aparece trabajo urgente nuevo:
1. Evaluar urgencia vs. trabajo actual
2. Si es verdaderamente urgente, ¿qué se elimina?
3. Discutir con product owner
4. Documentar el cambio
5. Comunicar a stakeholders
NUNCA:
├── Agregar trabajo silenciosamente
├── Dejar que ocurra scope creep
├── Fallar objetivo del sprint sin alertar temprano
└── Culpar al equipo por factores externos
Tracking de Burndown
BURNDOWN DEL SPRINT
═══════════════════
Puntos restantes por día:
48 │●
│ ●
40 │ ● ● (retraso)
│ ●
32 │ ●
│ ●
24 │ ●
│ ●
16 │ ●
│ ●
8 │ ●
│ ●
0 │──────────────────────────●
D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
Leyenda:
─── Burndown ideal
● Progreso real
Estado: En camino después de ajuste día 4
Pronóstico: Completar con 2 pts de buffer
Mejores Prácticas
Para Sprint Backlogs
- Usar datos de velocidad — No adivinar capacidad
- Dejar buffer — 10-15% para incógnitas
- Priorizar despiadadamente — Top items primero
- Listo significa listo — Aplicar Definition of Ready
- Proteger el compromiso — Resistir adiciones
Anti-Patrones
✗ Comprometerse sin datos de velocidad
✗ Sin buffer para incógnitas
✗ Agregar trabajo mid-sprint sin eliminar
✗ Items no refinados en el sprint
✗ Sin objetivo de sprint claro
✗ Equipo no participa en planning