6 min lectura • Guide 691 of 877
Mejorando Velocity del Equipo con el Tiempo
La mejora sostenible de velocity viene de eliminar fricción, no de trabajar más duro. GitScrum ayuda a trackear tendencias de velocity, identificar bloqueadores y cuellos de botella, y medir el impacto de mejoras de proceso con el tiempo.
Entendiendo Velocity
Qué Afecta Velocity
FACTORES DE VELOCITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FACTORES POSITIVOS (aumentan velocity): │
│ ✓ Composición estable del equipo │
│ ✓ Requisitos claros │
│ ✓ Buenas herramientas y automatización │
│ ✓ Baja deuda técnica │
│ ✓ Tiempo de enfoque protegido │
│ ✓ Colaboración fuerte del equipo │
│ ✓ Procesos eficientes │
│ │
│ FACTORES NEGATIVOS (disminuyen velocity): │
│ ✗ Cambios en miembros del equipo │
│ ✗ Requisitos poco claros/cambiantes │
│ ✗ Alta deuda técnica │
│ ✗ Interrupciones frecuentes │
│ ✗ Cambio de contexto │
│ ✗ Herramientas pobres │
│ ✗ Overhead de proceso │
│ │
│ FACTORES TEMPORALES: │
│ • Vacaciones/PTO │
│ • Enfermedad │
│ • Onboarding de nuevos miembros │
│ • Desafíos técnicos mayores │
│ • Issues de infraestructura │
│ │
│ CLAVE: Mejora sostenible significa abordar factores │
│ sistémicos, no presionar a la gente más duro. │
└─────────────────────────────────────────────────────────────┘
Línea Base de Velocity
ESTABLECIENDO LÍNEA BASE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRACKEAR 6-8 SPRINTS PARA LÍNEA BASE CONFIABLE: │
│ │
│ Sprint │ Velocity │ Notas │
│────────┼──────────┼──────────────────────────────────────│
│ 18 │ 28 │ Onboarding de nuevo miembro │
│ 19 │ 32 │ │
│ 20 │ 34 │ │
│ 21 │ 30 │ Feriados │
│ 22 │ 35 │ │
│ 23 │ 36 │ │
│ 24 │ 38 │ │
│ 25 │ 34 │ Dos miembros enfermos │
│ │
│ CÁLCULO DE LÍNEA BASE: │
│ Promedio: 33.4 puntos │
│ Rango: 28-38 puntos │
│ Desviación estándar: 3.2 puntos │
│ │
│ VELOCIDAD SOSTENIBLE: 33 puntos (usar para planning) │
│ │
│ BANDERAS ROJAS: │
│ • Variación >30% entre sprints │
│ • Tendencia consistente a la baja │
│ • Velocity "heroico" seguido de crash │
│ │
└─────────────────────────────────────────────────────────────┘
Estrategias de Mejora
Identificar Oportunidades
ANÁLISIS DE OPORTUNIDADES DE MEJORA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. TIEMPO PERDIDO │
│ ¿Dónde se pierde tiempo? │
│ • Esperando code review: 6h promedio │
│ • Esperando decisiones: 4h promedio │
│ • Reuniones: 8h/semana/persona │
│ │
│ 2. CUELLOS DE BOTELLA │
│ ¿Dónde se acumula trabajo? │
│ • QA tiene 12 items esperando │
│ • Solo 1 persona puede aprobar deploys │
│ │
│ 3. RETRABAJO │
│ ¿Cuánto se rehace? │
│ • 20% de PRs requieren cambios significativos │
│ • 15% de stories reabiertas por bugs │
│ │
│ 4. DEUDA TÉCNICA │
│ ¿Qué nos hace lentos? │
│ • Tests tardan 20 min en correr │
│ • Build tarda 15 min │
│ • Módulo X requiere 2x tiempo por complejidad │
│ │
│ PRIORIZAR POR IMPACTO × ESFUERZO │
│ │
└─────────────────────────────────────────────────────────────┘
Plan de Mejora
PLAN DE MEJORA DE VELOCITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRIMESTRE ACTUAL - OBJETIVOS: │
│ │
│ 1. REDUCIR TIEMPO DE CODE REVIEW │
│ De: 6h promedio │
│ A: 4h promedio │
│ Acciones: │
│ • Implementar SLA de 4h │
│ • Rotación de reviewer de turno │
│ • PRs más pequeños │
│ Impacto esperado: +5% velocity │
│ │
│ 2. REDUCIR TIEMPO DE BUILD │
│ De: 15 min │
│ A: 5 min │
│ Acciones: │
│ • Caching agresivo │
│ • Build incremental │
│ • Runners paralelos │
│ Impacto esperado: +3% velocity │
│ │
│ 3. MEJORAR CALIDAD DE REQUISITOS │
│ Reducir stories reabiertas de 15% a 5% │
│ Acciones: │
│ • Refinement más riguroso │
│ • Criterios de aceptación obligatorios │
│ • Spike para items inciertos │
│ Impacto esperado: +7% velocity │
│ │
│ OBJETIVO TOTAL: +15% velocity al final del quarter │
│ │
└─────────────────────────────────────────────────────────────┘
Tracking de Progreso
DASHBOARD DE VELOCITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TENDENCIA DE VELOCITY (12 sprints): │
│ │
│ 40 │ ████ │
│ 35 │ ████ ████ ████ ████ │
│ 30 │ ████ ████ ████ │
│ 25 │ ████ │
│ 20 │ │
│ └───────────────────────────────────────────── │
│ S14 S15 S16 S17 S18 S19 S20 S21 S22 S23 │
│ │
│ LÍNEA BASE: 32 | ACTUAL: 38 | MEJORA: +19% │
│ │
│ FACTORES CONTRIBUYENTES: │
│ • SLA de review implementado (S18): +8% │
│ • Build time reducido (S20): +5% │
│ • Requisitos mejorados (S22): +6% │
│ │
│ PRÓXIMOS PASOS: │
│ • Continuar monitoreando │
│ • Sostener mejoras │
│ • Identificar próxima oportunidad │
│ │
└─────────────────────────────────────────────────────────────┘
Sostenibilidad
VELOCITY SOSTENIBLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEÑALES DE ALERTA: │
│ │
│ ⚠️ Velocity aumentó pero: │
│ • Overtime aumentó │
│ • Calidad bajó │
│ • Satisfacción del equipo bajó │
│ • Deuda técnica aumentó │
│ │
│ → Esta mejora NO es sostenible │
│ │
│ ✓ MEJORA SOSTENIBLE: │
│ • Velocity aumentó │
│ • Horas trabajadas estables │
│ • Calidad igual o mejor │
│ • Equipo reporta menos estrés │
│ • Deuda técnica estable o bajando │
│ │
│ REGLA: Nunca sacrifiques salud del equipo por velocity │
│ │
│ REVISIÓN MENSUAL: │
│ ☐ ¿Velocity subió? │
│ ☐ ¿Overtime estable (<5%)? │
│ ☐ ¿Bugs escapados estables o bajando? │
│ ☐ ¿Satisfacción del equipo 4+/5? │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Eliminar fricción no presionar más duro
- Un cambio a la vez para medir impacto
- Trackear tendencias no sprints individuales
- Balance calidad-velocity siempre
- Sostenibilidad primero sobre ganancias cortas
- Equipo decide mejoras no management impone