GitScrum
Probar gratis
7 min lectura • Guide 220 of 877

Gestionando Velocity del Sprint

La velocity es la medida del trabajo que tu equipo completa por sprint. Cuando se rastrea bien, permite planning preciso, compromisos realistas, y forecasting confiable. Cuando se usa mal, se convierte en un target de gaming que distorsiona comportamiento. Usa velocity como herramienta de planning, no como métrica de performance.

Entendiendo Velocity

Velocity ESVelocity NO ES
Herramienta de planningMétrica de performance
Medida a nivel equipoComparación individual
Relativa en el tiempoComparable entre equipos
Habilitador de forecastsMeta a maximizar
DescriptivaPrescriptiva

Rastreando Velocity

Método de Cálculo

CÁLCULO DE VELOCITY
═══════════════════

COMPLETADOS DEL SPRINT:
─────────────────────────────────────
Sprint 24 items completados:
├── GS-100: Login de usuario (3 pts) ✓
├── GS-101: Reset de password (2 pts) ✓
├── GS-102: Página de perfil (5 pts) ✓
├── GS-103: Upload de avatar (3 pts) ✓
├── GS-104: Página de settings (5 pts) ✗ (80% completo)
├── GS-105: Bug fixes (3 pts) ✓
└── GS-106: Templates de email (2 pts) ✓

Cálculo:
├── Completados: 3 + 2 + 5 + 3 + 3 + 2 = 18 pts
├── NO contado: GS-104 (no done = no cuenta)
└── Velocity: 18 puntos

REGLA:
├── Solo contar items DONE
├── Done = cumple Definition of Done
├── Crédito parcial = sin crédito
└── Carryover = próximo sprint

Historial de Velocity

TRACKING DE HISTORIAL DE VELOCITY
═════════════════════════════════

HISTORIAL DE SPRINTS:
─────────────────────────────────────
Sprint   Comprometido   Completado   Velocity
───────────────────────────────────────────────
  19         28            26          26
  20         30            28          28
  21         32            24          24  ← Bajo
  22         28            27          27
  23         30            29          29
  24         30            18          18  ← Bajo (feriado)
───────────────────────────────────────────────

ANÁLISIS:
├── Promedio (6 sprints): 25.3 pts
├── Promedio (recientes 3): 24.7 pts
├── Punto bajo: 18 (explicable: feriados)
├── Punto alto: 29
└── Rango estable: 24-29

RECOMENDACIÓN:
├── Planificar próximo sprint: 24-26 pts
├── Usar estimación conservadora
├── Considerar factores conocidos
└── No sobre-comprometer

Gráfico de Velocity

VISUALIZACIÓN DE VELOCITY
═════════════════════════

GRÁFICO DE VELOCITY:
─────────────────────────────────────
 30 │          ▓
 28 │    ▓     ║     ▓
 26 │ ▓  ║     ║     ║  ▓
 24 │ ║  ║  ▓  ║     ║  ║
 22 │ ║  ║  ║  ║     ║  ║
 20 │ ║  ║  ║  ║     ║  ║
 18 │ ║  ║  ║  ║  ▓  ║  ║
    └─┴──┴──┴──┴──┴──┴──┴───
      19 20 21 22 23 24 25
      
─ ─ Promedio: 25 pts

INTERPRETACIÓN:
├── Sprint 21: Bajo promedio (investigar)
├── Sprint 23: Cerca de promedio (normal)
├── Sprint 24: Significativamente bajo (feriados)
├── Tendencia: Estable con varianza explicable
└── Acción: Ninguna necesaria, equipo consistente

Usando Velocity para Planning

Estableciendo Compromisos

COMPROMISO DE SPRINT USANDO VELOCITY
════════════════════════════════════

PASO 1: Calcular Velocity de Planning
─────────────────────────────────────
Últimos 6 sprints: 26, 28, 24, 27, 29, 18

Método A: Promedio simple
(26 + 28 + 24 + 27 + 29 + 18) / 6 = 25.3

Método B: Excluir outliers
Remover 18 (sprint de feriados)
(26 + 28 + 24 + 27 + 29) / 5 = 26.8

Método C: Tendencia reciente (últimos 3)
(27 + 29 + 18) / 3 = 24.7 (sesgado por feriado)

ELEGIR: 25-27 puntos es razonable

PASO 2: Ajustar por Factores Conocidos
─────────────────────────────────────
├── Miembro en vacaciones: -15%
├── Nuevo miembro onboarding: -10%
├── Sin factores especiales: Usar promedio
└── Próximo sprint: 25 × 0.85 = 21 pts

PASO 3: Comprometer Trabajo
─────────────────────────────────────
Sprint backlog:
├── Items alta prioridad: 18 pts
├── Items media prioridad: 8 pts
├── Capacidad disponible: 21 pts
└── Comprometer: 18 + 3 stretch = 21 pts

Forecasting

FORECASTING BASADO EN VELOCITY
══════════════════════════════

TRABAJO RESTANTE: 120 story points

VELOCITY: 25 pts/sprint (promedio)

FORECAST SIMPLE:
─────────────────────────────────────
120 pts / 25 pts por sprint = 4.8 sprints
4.8 × 2 semanas = 9.6 semanas
→ Aproximadamente 10 semanas

FORECAST CON RANGO (más realista):
─────────────────────────────────────
Optimista (velocity 29): 120/29 = 4.1 sprints
Esperado (velocity 25): 120/25 = 4.8 sprints
Pesimista (velocity 21): 120/21 = 5.7 sprints

Resultado:
├── Mejor caso: 8 semanas
├── Esperado: 10 semanas
├── Peor caso: 12 semanas
└── Comunicar rango, no fecha única

FACTORES A CONSIDERAR:
├── Feriados en el período
├── Ausencias conocidas
├── Nuevos descubrimientos
├── Riesgo técnico
└── Agregar buffer para desconocidos

Problemas de Velocity

Declive de Velocity

DIAGNOSTICANDO DECLIVE DE VELOCITY
══════════════════════════════════

VELOCITY BAJÓ:
─────────────────────────────────────
Reciente: 28 → 24 → 21 → 18
Patrón: Declive consistente

INVESTIGAR:
─────────────────────────────────────
1. ¿CAMBIOS EN EQUIPO?
   ├── Miembro se fue/vacaciones
   ├── Nuevo miembro onboarding
   ├── Cambio de manager
   └── Cambios de rol

2. ¿PROBLEMAS DE PROCESO?
   ├── Más reuniones
   ├── Más interrupciones
   ├── Tiempos de review más largos
   ├── Problemas de deployment
   └── Prácticas cambiadas

3. ¿CAMBIOS EN TRABAJO?
   ├── Trabajo más complejo
   ├── Más incógnitas
   ├── Deuda técnica
   ├── Código legacy
   └── Tipo diferente de trabajo

4. ¿DRIFT DE ESTIMACIÓN?
   ├── Puntos significan algo diferente ahora
   ├── Estimaciones más honestas
   ├── Menos infladas
   └── En realidad: Mismo trabajo, mejores estimaciones

5. ¿FACTORES EXTERNOS?
   ├── Cambios en la empresa
   ├── Cambios de prioridades
   ├── Problemas de moral
   └── Burnout

ACCIÓN:
├── Discutir en retrospectiva
├── Identificar causa raíz
├── Abordar problemas sistémicos
├── No solo empujar más fuerte

Gaming de Velocity

EVITANDO GAMING DE VELOCITY
═══════════════════════════

PATRONES DE GAMING:
─────────────────────────────────────
✗ Inflar estimaciones
  "Esto son 8 puntos, no 5"
  Resultado: Velocity más alta, mismo trabajo

✗ Dividir artificialmente
  Una story de 8 → Cuatro stories de 2
  Resultado: Más puntos, mismo trabajo

✗ Solo contar trabajo fácil
  Evitar tareas difíciles, hacer simples
  Resultado: Puntos suben, valor baja

✗ Marcar incompleto como done
  "Está 90% done, cuéntalo"
  Resultado: Velocity falsa, deuda crece

POR QUÉ OCURRE EL GAMING:
─────────────────────────────────────
├── Velocity tratada como métrica de performance
├── Presión para aumentar velocity
├── Comparación entre equipos
├── Management la usa para evaluación
└── Respuesta natural a incentivos

PREVENCIÓN:
─────────────────────────────────────
├── Velocity es solo para planning
├── Nunca comparar equipos
├── Nunca vincular a performance
├── Celebrar outcomes, no puntos
├── Enfocarse en valor entregado
└── Rastrear pero no targetear

Soluciones Relacionadas con GitScrum

Conclusión

La velocity es una herramienta poderosa de planning cuando se usa correctamente—y una métrica destructiva cuando se usa mal. GitScrum rastrea velocity automáticamente desde items completados, proporcionando tendencias históricas, promedios, y forecasts. La clave es usar velocity para informar planning y forecasting, nunca para evaluar performance o comparar equipos. Enfócate en mejorar el sistema—removiendo bloqueadores, reduciendo overhead, y creando ritmo sostenible—y la velocity mejorará naturalmente.

Volver a Guías Prácticas