Publicaciones

Velocidad del sprint: cómo medirla, hacer pronósticos y dejar de usarla mal

Ilustración de un panel de sprint con un velocímetro y una fila de gráficos de barras ascendentes que representan los story points completados por sprint, estilo editorial plano y moderno con vibrantes tonos morados y azules, un pequeño equipo ágil revisando el gráfico en conjunto

Kelly Lewandowski

Última actualización 07/06/20268 min de lectura

La velocidad es la métrica ágil más fácil de calcular y la más fácil de arruinar. Suma los story points que tu equipo completó el sprint pasado. Eso es todo. El problema empieza en el momento en que alguien trata ese número como un objetivo, un puntaje de productividad o una promesa de entrega exacta. La velocidad tiene exactamente dos funciones legítimas: ayudarte a pronosticar de forma aproximada cuándo terminará un bloque de trabajo, y darle al equipo una verificación de cordura sobre cuánto comprometer para el próximo sprint. Usada para cualquier otra cosa, hace más daño que bien. Aquí te explicamos cómo hacer bien ambas cosas, y cómo detectar el mal uso antes de que se propague.

Qué es realmente la velocidad del sprint

La velocidad es la cantidad de story points que tu equipo completó en un sprint. Completado significa terminado según tu Definición de Terminado, no "en QA" ni "casi mergeado". El trabajo a medias cuenta como cero. Una historia que se arrastra suma puntos en el sprint en el que realmente termina, no en el que empezó. Esa es toda la definición. La velocidad no es una medida del esfuerzo, las horas ni de lo duro que trabajó la gente. Es una medida del resultado en la propia moneda de story points de tu equipo, y por eso mismo solo significa algo dentro de ese equipo en concreto.

Los puntos son relativos al equipo

Los puntos de un equipo están calibrados según ese equipo. El 8 de un equipo es el 3 de otro. Este es el único hecho que invalida la mayoría de las comparaciones de velocidad, y volveremos sobre él.

Cómo calcularla (y por qué un solo número miente)

La fórmula básica es un promedio de tus sprints recientes: Velocidad promedio = puntos totales completados ÷ número de sprints Usa al menos 3 sprints, idealmente 6 o más, y cuenta únicamente sprints con un equipo razonablemente estable. Aquí tienes una serie realista de seis sprints:

22, 28, 19, 31, 24, 26

Puntos completados por sprint

Velocidad promedio

19–31

Rango real

El promedio es 25. Pero ningún sprint entregó realmente 25, y la dispersión real va de 19 a 31. Si planificas cada sprint en torno a "25", te sobrecomprometerás en los sprints lentos y dejarás capacidad libre en los rápidos. El promedio es un punto de partida para la conversación, no un contrato. Por eso la Calculadora de velocidad del sprint reporta un rango y un puntaje de consistencia junto al promedio. Pega tus últimos sprints y te dice no solo el punto medio sino qué tan fiable es ese punto medio. Un equipo que hace 24, 25, 26 está en una situación muy distinta a uno que hace 12, 38, 25, aunque ambos promedien 25.

Pronósticos: usa rangos, no números únicos

Aquí es donde la mayoría de los consejos sobre velocidad se equivocan. El clásico es "backlog ÷ velocidad promedio = sprints hasta terminar". Con un backlog de 200 puntos y una velocidad promedio de 25, eso da 8 sprints. Limpio, seguro y casi con certeza incorrecto, porque pretende que tu velocidad no tiene varianza. Tu velocidad sí tiene varianza, así que tu pronóstico también debería tenerla. La versión sencilla y honesta es el método de los tres pronósticos: pronostica con una velocidad conservadora, una probable y una optimista.

Escenario	Velocidad usada	Backlog de 200 puntos
Conservador	Promedio de tus 3 sprints más lentos (~22)	~10 sprints
Probable	Promedio general (25)	8 sprints
Optimista	Promedio de tus 3 sprints más rápidos (~28)	~7 sprints

Ahora puedes decirle a un stakeholder "entre 7 y 10 sprints, lo más probable 8" en lugar de un único número que después tendrás que desdecir. Como Mike Cohn y otros han defendido desde hace tiempo, una afirmación como "tenemos un 90% de confianza en que esto cae entre el sprint 7 y el sprint 10" es a la vez más útil y más defendible que la falsa precisión.

Da siempre un rango

Cuando alguien te pida una fecha, dale dos: la optimista y la conservadora. Un rango comunica la incertidumbre con honestidad y te protege cuando la realidad cae en algún punto intermedio, que es casi siempre lo que ocurre.

Para los equipos que quieren probabilidades reales, la simulación de Monte Carlo es el siguiente paso. En lugar de tres escenarios elegidos a mano, ejecuta miles de futuros simulados tomando muestras al azar de tus sprints históricos, y luego reporta los resultados como percentiles: una finalización en el percentil 50 (la mediana), una en el 85 y una en el 95. "85% de probabilidad de terminar para el sprint 9" es una afirmación mucho más sólida que la que cualquier promedio puede ofrecer. No necesitas una única estimación puntual; necesitas una distribución. Ilustración de un cono de incertidumbre que se abre desde un punto de partida hacia una bandera de meta, con múltiples trayectorias de probabilidad en bandas degradadas de azul y morado, estilo vectorial plano y moderno, sin texto ni números

Ilustración de un cono de incertidumbre que se abre desde un punto de partida hacia una bandera de meta, con múltiples trayectorias de probabilidad en bandas degradadas de azul y morado, estilo vectorial plano y moderno, sin texto ni números

Cómo los equipos usan mal la velocidad

Scrum.org ha llegado al punto de publicar un artículo titulado "Story Points are not the Problem, Velocity is" (los story points no son el problema, la velocidad sí). El dimensionamiento de los puntos es en su mayoría inofensivo; el daño viene de lo que los gerentes hacen con el número de velocidad resultante. Estos son los cuatro modos de fallo a los que hay que prestar atención.

⚖️Comparar equipos

El Equipo A hace 40, el Equipo B hace 25, así que el Equipo A es "más productivo". Falso. Los puntos son relativos al equipo, así que la comparación no mide nada. Solo le enseña al Equipo B a inflar.

📈Como métrica de productividad

En cuanto la velocidad se convierte en un número por el que se mide a la gente, deja de medir el resultado y empieza a medir cuánta presión siente el equipo. La ley de Goodhart en acción.

🎯Como compromiso

"Hiciste 30 el sprint pasado, así que comprométete a 30." Esto convierte un pronóstico en una cuota y empuja al equipo a inflar las estimaciones hasta que el número sea seguro de alcanzar.

🎲A partir de un solo sprint

Un sprint es ruido. Un día festivo, una caída del sistema o un bug espinoso lo mueven de forma drástica. La velocidad solo significa algo como tendencia a lo largo de varios sprints.

El hilo común: cada mal uso convierte la velocidad de una herramienta que el equipo usa en un objetivo contra el que se juzga al equipo. Una vez que ocurre ese giro, el número se manipula y pierdes la señal honesta con la que empezaste.

La espiral mortal de la inflación

Presiona a un equipo para que aumente su velocidad y lo hará, al instante, dimensionando en silencio el mismo trabajo con puntos más altos. La velocidad sube, nada se entrega más rápido, y ahora tus datos históricos quedan envenenados para los pronósticos. La métrica que estabas optimizando destruye lo único para lo que servía.

La velocidad bien hecha

Usada como una ayuda interna de planificación y nada más, la velocidad se gana su lugar. Una breve lista de verificación para mantenerla honesta:

Cuenta solo el trabajo totalmente terminado según tu Definición de Terminado.

Promedia sobre 6 o más sprints y observa la tendencia, no un número aislado.

Pronostica con rangos o percentiles, nunca con una única fecha de "terminado para".

Restablece la línea base tras cambios importantes en el equipo; la velocidad antigua no se transfiere.

Nunca muestres la velocidad en una diapositiva que compare equipos o personas.

Conserva la conversación de estimación; la discusión importa más que los puntos.

Ese último punto es el que los equipos olvidan. La velocidad es un subproducto de una buena estimación, no su objetivo. El valor del planning poker está en la conversación que saca a la luz la complejidad oculta antes de que te muerda a mitad del sprint. El número que resulta no es más que contabilidad.

La velocidad no es tu única opción

Si la velocidad sigue siendo usada como arma en tu equipo, o tus historias varían demasiado en tamaño como para que los puntos sean estables, tienes alternativas. Algunos equipos abandonan la estimación por completo y pronostican directamente a partir del throughput. Una opción más ligera es conservar la velocidad pero apoyarse en las métricas de flujo para las partes que hace mal. El throughput (elementos terminados por sprint) y el cycle time (cuánto tarda un elemento desde el inicio hasta terminar) miden la entrega con marcas de tiempo reales en lugar de estimaciones.

Pregunta	Mejor métrica
Cuánto comprometer en un sprint	Velocidad o throughput
Cuándo terminará este backlog	Monte Carlo sobre velocidad/throughput
Por qué el trabajo tarda tanto	Cycle time y trabajo en progreso
Estamos mejorando con el tiempo	Tendencia del cycle time

La mayoría de los equipos maduros terminan usando ambas: la velocidad para la conversación a nivel de sprint, las métricas de flujo para pronosticar la entrega y detectar cuellos de botella. Responden preguntas distintas, y ninguna es un marcador de productividad.

En resumen

La velocidad es una linterna, no un velocímetro. Ayuda al equipo a ver de forma aproximada cuánto puede asumir y, aproximadamente, cuándo terminará un cuerpo de trabajo. Apúntala hacia las personas en lugar del trabajo y dejará de decir la verdad. Mídela a lo largo de varios sprints, pronostica en rangos y mantenla dentro del equipo. Cuando necesites que los números se calculen rápido, la Calculadora de velocidad del sprint convierte tus últimos sprints en un promedio, un rango realista, un puntaje de consistencia y un pronóstico de backlog en unos segundos. Para el lado de la estimación que la alimenta, el planning poker mantiene el foco donde corresponde: en la conversación, no en el marcador.

Al menos 3 para obtener un promedio aproximado, pero 6 o más antes de confiar en ella para pronosticar. Con menos que eso, un solo sprint inusual lo distorsiona todo. El equipo también debería ser razonablemente estable a lo largo de esos sprints.

Solo si esos elementos se estimaron en puntos y se terminaron dentro del sprint. Muchos equipos dejan los bugs y el trabajo de soporte sin puntos y los siguen por separado, lo que mantiene la velocidad enfocada en la entrega de funcionalidades planificadas. Elige un enfoque y mantén la consistencia para que tu historial siga siendo comparable.

Los story points se calibran por equipo, así que el 5 de un equipo es el 13 de otro. Comparar los números en bruto no mide nada real y presiona a los equipos a inflar sus estimaciones. Si necesitas una vista entre equipos, fíjate en los resultados entregados o en el cycle time, no en los puntos.

No. La velocidad mide el resultado en una unidad específica del equipo, no el valor entregado ni el esfuerzo invertido. Un equipo puede subir su velocidad sin entregar nada más útil, simplemente dimensionando el trabajo con puntos más altos. Trátala como un insumo de planificación, nunca como una métrica de desempeño.