Sprint Velocity en Scrum: Guia Completa 2026

Sprint Velocity es una metrica fundamental en Agile y Scrum que mide la cantidad de trabajo que un equipo de desarrollo puede completar en un solo Sprint.

La Velocity tipicamente se mide en story points - unidades relativas que estiman la complejidad y esfuerzo de completar una historia de usuario.

Al final de cada Sprint, el equipo calcula su Sprint Velocity sumando los story points de todas las historias de usuario completadas exitosamente.

Cuando se entiende y usa correctamente, la Velocity transforma la planificacion de Sprints y releases de conjeturas en decisiones basadas en datos historicos.

Respuesta Rapida: Sprint Velocity de un Vistazo

Aspecto	Detalles
Que mide	Story points completados por Sprint
Calculo	Suma de story points de historias completamente terminadas
Cuando usar	Sprint Planning, pronostico de releases, analisis de retrospectiva
Cuando NO usar	Comparar equipos, evaluar individuos, como meta a maximizar
Se estabiliza despues de	3-5 Sprints para equipos nuevos
Metrica relacionada	Throughput (items completados, sin importar el tamano)

Que es Sprint Velocity en Agile?

Sprint Velocity, a menudo simplemente llamada "Velocity", representa la cantidad de story points completados por un equipo dentro de un solo Sprint.

Si bien algunos equipos prefieren usar otras mediciones como horas o historias completadas, el concepto fundamental permanece igual: Velocity cuantifica la cantidad de trabajo que un equipo logra durante un Sprint.

Es crucial reconocer que Sprint Velocity es una metrica descriptiva, no una metrica de exito. Sirve para medir la capacidad de tu equipo en lugar de ser un objetivo a mejorar constantemente.

Como Calcular Sprint Velocity

La medicion de Sprint Velocity es directa.

Al final de cada Sprint, suma los story points totales asociados con cada historia de usuario completamente terminada.

Esta suma constituye la metrica de Velocity de tu equipo para ese Sprint.

Ejemplo de calculo:

Si tu equipo completa tres historias de usuario:

• Historia A (4 puntos) - completamente terminada
• Historia B (2 puntos) - completamente terminada
• Historia C (3 puntos) - completamente terminada

Tu Velocity para ese Sprint es 9 Story Points.

Importante: las historias de usuario incompletas no deben incluirse en el calculo, aunque esten al 90% completadas.

Recuerda: solo los PBIs que cumplen la Definition of Done cuentan.

Calcular la Velocity Promedio

Para obtener tu Sprint Velocity promedio, suma los story points de los ultimos 3-5 Sprints y divide por el numero de Sprints.

Ejemplo:

• Sprint 1: 28 puntos
• Sprint 2: 32 puntos
• Sprint 3: 36 puntos

Velocity promedio = (28 + 32 + 36) / 3 = 32 Story Points por Sprint

Por Que los Equipos Miden Sprint Velocity?

Sprint Velocity ofrece varios beneficios para los equipos Agile:

1. Sprint Planning Mejorado

Velocity empodera a los equipos para hacer planes de Sprint mas precisos, proporcionando perspectivas sobre cuantos story points pueden lograr realisticamente en un Sprint.

2. Visualizando el Progreso

Visualizar Sprint Velocity a lo largo del tiempo, a menudo en forma de un grafico Burn-down, proporciona perspectivas valiosas sobre el progreso durante el Sprint.

3. Enfoque en Retrospectivas

Las Sprint Retrospectives son una oportunidad ideal para usar Sprint Velocity. Puede servir como punto focal para identificar problemas potenciales o evaluar cambios de proceso recientes.

4. Oportunidades de Optimizacion

• Dominar el Refinamiento del Backlog: Backlogs bien refinados permiten a los miembros del equipo comenzar tareas con toda la informacion necesaria.
• Automatizacion: Automatizar procesos de prueba puede llevar a mejoras significativas en Velocity.
• Observar la Dinamica del Equipo: Abordar cambios o deficiencias en el equipo tempranamente.
• Gestionar Dependencias Externas: Identificar y abordar retrasos causados por factores externos.

Velocity para Planificacion de Releases y Pronosticos

Una de las aplicaciones mas poderosas de Sprint Velocity es el pronostico de releases.

Pronostico de Release Paso a Paso

1. Contar story points restantes en el Product Backlog para el release planeado
2. Calcular la Velocity promedio de los ultimos 3-5 Sprints
3. Dividir puntos restantes por Velocity promedio para estimar Sprints necesarios
4. Multiplicar por la duracion del Sprint para obtener tiempo en calendario

Ejemplo:

• Scope de release restante: 160 Story Points
• Velocity promedio: 32 puntos por Sprint
• Sprints estimados necesarios: 160 / 32 = 5 Sprints
• Duracion del Sprint: 2 semanas
• Fecha estimada de release: 10 semanas desde ahora

Estabilizacion de Velocity: Que Esperar

Durante los primeros Sprints de un equipo, la Velocity puede variar significativamente. Este periodo se caracteriza por:

• Calibracion de estimaciones de story points
• Reuniones mas largas mientras el equipo aprende Scrum
• Miembros del equipo familiarizandose con el codigo base y el dominio
• Evolucion de la Definition of Done

Es aconsejable esperar una Velocity estable solo despues de tres a cinco Sprints, cuando hay suficientes datos disponibles para evaluaciones significativas.

Mejorando Sprint Velocity

Para estabilizar y mejorar la Velocity de tu equipo:

• Escribir historias de usuario claras y concisas
• Mantener una composicion y tamano de equipo consistentes
• Usar Sprint Retrospectives para identificar areas de mejora
• Eliminar dependencias que obstaculicen el progreso
• Desarrollar una Definition of Done robusta
• Priorizar calidad sobre velocidad - el apresuramiento genera deuda tecnica
• Asignar tiempo suficiente para pruebas exhaustivas y code review

Limitaciones de Velocity

Si bien Velocity es una herramienta de planificacion util, es crucial reconocer sus limitaciones:

1. Velocity es especifica del equipo: Comparar la Velocity de diferentes equipos no es productivo.
2. Velocity puede variar por cambios en la composicion del equipo: Si un miembro entra o sale, puede afectar la Velocity.
3. Velocity no es medida de valor: Una Velocity alta no significa necesariamente que el equipo entrega features de alto valor.
4. Velocity puede manipularse: Si se usa como metrica de rendimiento, los equipos inflaran estimaciones.
5. Velocity no muestra calidad del trabajo: Alta Velocity con alta deuda tecnica puede ralentizar futuros Sprints.

Anti-Patrones de Velocity a Evitar

Anti-Patron 1: Usar Velocity como Meta

Problema: El management establece metas de Velocity ("deben lograr 50 puntos por Sprint").

Por Que es Danino: Los equipos inflan estimaciones de story points sin aumentar la produccion real.

Solucion: Usar Velocity como input de planificacion, nunca como meta de rendimiento.

Anti-Patron 2: Comparar Velocity entre Equipos

Problema: "El Equipo A entrega 60 puntos por Sprint. El Equipo B solo 30."

Por Que es Danino: Las escalas de story points son especificas del equipo. La comparacion es sin sentido y desmoralizante.

Solucion: Comparar la tendencia de Velocity de cada equipo a lo largo del tiempo, no numeros absolutos entre equipos.

Anti-Patron 3: Credito Parcial por Historias Incompletas

Problema: Los equipos dan credito parcial de Velocity por historias que estan al 80% completadas.

Por Que es Danino: Las historias parciales generan datos de Velocity falsos y socavan la Definition of Done.

Solucion: Aplicar la regla todo-o-nada. Si una historia no cumple completamente la Definition of Done, contribuye cero a la Velocity.

Anti-Patron 4: Inflation de Estimaciones por Presion

Problema: El equipo infla estimaciones para que su Velocity "parezca" mas alta.

Por Que es Danino: Destruye la utilidad de la Velocity para la planificacion de releases y erosiona la confianza.

Solucion: Recalibrar regularmente comparando historias actuales de 5 puntos con historias de 5 puntos de hace seis meses.

Anti-Patron 5: Ignorar Caidas Significativas de Velocity

Problema: Un Sprint donde la Velocity cae un 40% se trata como variacion normal sin investigacion.

Por Que es Danino: Las caidas grandes (mas del 25%) tipicamente senalan problemas reales - deuda tecnica, conflictos de equipo, bloqueadores.

Solucion: Cualquier Sprint con una caida de Velocity superior al 25% del promedio actual debe investigarse en la retrospectiva.

Velocity vs. Throughput: Que Deberias Rastrear?

Aspecto	Velocity	Throughput
Que se cuenta	Story points completados	Numero de items completados
Estimacion requerida	Si (story points)	No
Mejor para	Planificar capacidad del Sprint, pronostico de releases	Eficiencia de flujo, analisis de cycle time
Riesgo de manipulacion	Mayor	Menor

Muchos equipos Agile maduros rastrean ambos: Velocity para planificacion de Sprints y Throughput para analisis de flujo.

Regulando la Sprint Velocity de tu Equipo

La consistencia en Sprint Velocity es fundamental:

1. Clarificar Historias de Usuario: Asegurar que las historias de usuario sean claras y comprensibles antes del Sprint.

2. Mantener Consistencia: Evitar cambios frecuentes en composicion del equipo, duracion del Sprint o procesos.

3. Establecer Definition of Done Uniforme: Criterios claros mejoran la precision de estimaciones. Define "hecho".

4. Realizar Sprint Retrospectives: Usar la naturaleza iterativa de Agile para mejorar continuamente.

5. Rastrear la Tendencia, no el Numero: No fijarse en numeros individuales de Velocity. Rastrear el promedio movil de 5-10 Sprints.

Modelo de Madurez de Velocity

Fase 1: Conciencia (Sprints 1-6)

El equipo aprende story points y estimacion. La Velocity varia significativamente (variacion del 50%+ es normal). No usar Velocity para pronosticos externos.

Fase 2: Predictibilidad (Sprints 7-15)

La Velocity comienza a estabilizarse (variacion dentro del 20-25%). El equipo usa la Velocity con confianza para Sprint Planning. Se rastrea el promedio movil.

Fase 3: Optimizacion (Sprint 16+)

La Velocity es estable y predecible. El equipo usa Velocity para pronosticos de releases orientados a stakeholders. Se rastrea Throughput junto con Velocity para analisis de flujo.

Conclusion

Sprint Velocity es un instrumento valioso en el conjunto de herramientas Agile, pero su uso efectivo requiere una comprension matizada.

Puntos clave:

• Calcular Velocity como suma de story points de historias completamente terminadas
• Usar Velocity para Sprint Planning y pronostico de releases, nunca como meta de rendimiento
• Esperar 3-5 Sprints antes de que la Velocity sea confiable
• Rastrear Throughput junto con Velocity para un panorama completo de la salud del flujo
• Nunca comparar Velocity entre equipos
• Investigar inmediatamente caidas superiores al 25% - senalan problemas reales

El exito Agile depende finalmente de la capacidad del equipo para adaptarse y alinear sus practicas con el objetivo general de entregar valor a los clientes.

Seguir Leyendo

Preguntas Frecuentes (FAQs)