Velocity en Agile: Cómo Medir el Rendimiento del Equipo
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
El velocity ágil es uno de los números más prácticos que un equipo Scrum puede rastrear. Le indica, en promedio, cuánto trabajo termina realmente su equipo en un sprint, lo cual es la base de cualquier pronóstico honesto de lanzamiento o plan de capacidad.
La mayoría de los equipos escuchan sobre el velocity al principio de su recorrido ágil, lo usan mal como una puntuación de desempeño, y luego se preguntan por qué genera presión en lugar de claridad. Esta guía explica qué es el velocity, cómo calcularlo correctamente y cómo usarlo como herramienta de pronóstico sin manipular el número.
¿Qué es el velocity en Agile?
El velocity ágil es el número promedio de story points que un equipo completa en un sprint. Se calcula dividiendo el total de puntos terminados a lo largo de varios sprints recientes entre el número de esos sprints.
Esa es toda la definición. El velocity no mide calidad, velocidad, eficiencia ni esfuerzo. Mide el rendimiento completado durante una ventana de tiempo fija, nada más.
La palabra clave es "completado". Los story points que se comenzaron pero no se terminaron antes de que terminara el sprint no cuentan para el velocity. Aquí no existe el crédito parcial. Esta rigurosidad es lo que hace del velocity un insumo de pronóstico confiable: si un equipo tiene un velocity promedio de 42 puntos, se pueden proyectar sprints futuros con confianza razonable porque el número refleja lo que realmente se entregó, no lo que se intentó.
Datos clave
- Los equipos que rastrean el velocity durante al menos 6 sprints producen estimaciones de fecha de lanzamiento un 40% más precisas que los equipos que estiman puramente por instinto (Scrum Alliance State of Scrum, 2023).
- El velocity promedio de un equipo Scrum oscila entre 20 y 60 story points por sprint, aunque el número en sí es menos importante que su estabilidad a lo largo del tiempo (VersionOne State of Agile, 2023).
- Aproximadamente el 60% de los equipos ágiles reporta usar el velocity como su métrica principal de planificación de capacidad, lo que la convierte en la medida de rendimiento más adoptada en Scrum (Digital.ai State of Agile Report, 2023).
Cómo calcular el velocity
La fórmula es directa.
Velocity = Total de story points completados / Número de sprints medidos
Use los últimos 3 a 5 sprints para un promedio móvil. Menos de 3 sprints da una imagen ruidosa; más de 7 comienza a mezclar datos de períodos en los que el equipo tenía una composición o hábitos de estimación distintos.
Aquí hay un ejemplo resuelto para un equipo que corre sprints de 2 semanas:
| Sprint | Puntos comprometidos | Puntos completados |
|---|---|---|
| Sprint 1 | 48 | 42 |
| Sprint 2 | 45 | 44 |
| Sprint 3 | 50 | 39 |
| Sprint 4 | 46 | 45 |
Velocity promedio móvil (4 sprints): (42 + 44 + 39 + 45) / 4 = 42.5 puntos
El velocity de trabajo del equipo es de aproximadamente 42 puntos por sprint. Note que el número comprometido no importa para el cálculo. Lo que importa es lo que cruzó la línea de "hecho" antes de que terminara el sprint. Si el Sprint 3 parece bajo, investigue la causa (¿cambio de alcance? ¿bloqueo a mitad de sprint? ¿día festivo?) en lugar de descartarlo o inflarlo.
Cómo usar el velocity para pronosticar
Una vez que tiene un velocity estable, puede responder la pregunta que todo stakeholder eventualmente hace: "¿Cuándo estará listo esto?"
El enfoque es simple. Sume los story points de su backlog restante (o la porción del backlog para un lanzamiento determinado), luego divida entre su velocity promedio.
Sprints para completar = Puntos restantes del backlog / Velocity promedio
Supongamos que su equipo tiene 210 puntos restantes en el backlog de un lanzamiento y un velocity de 42. Eso son 5 sprints, o 10 semanas con una cadencia de 2 semanas. Ese es su pronóstico.
Algunas prácticas hacen esto más útil en la realidad:
- Use un rango, no una estimación puntual. Ingrese el resultado de su sprint reciente más bajo y el más alto para obtener una banda de confianza. "Entre 4.5 y 6 sprints" es más honesto que "exactamente 5".
- Vuelva a pronosticar cada sprint. A medida que el equipo completa trabajo, agrega elementos nuevos o elimina alcance, la proyección cambia. Trátelo como un número vivo, no como un contrato.
- Conecte el velocity con su hábito de refinamiento del backlog. Los pronósticos de velocity son tan buenos como la planificación de sprint que mantiene el backlog dimensionado y ordenado. Si las estimaciones se desvían o el backlog se vuelve obsoleto, el velocity pierde su poder de pronóstico.
- Vincúlelo a los hitos del roadmap. Si su roadmap dice que una funcionalidad se lanza en el Q3, trabaje hacia atrás desde la fecha límite para ver cuántos sprints tiene, multiplique por el velocity, y verifique si el alcance restante encaja. Si no encaja, tiene una conversación de alcance o cronograma que debe tener temprano, no en la fecha límite.
Este método de pronóstico también combina bien con planning poker, que ayuda a mantener calibradas las estimaciones de story points en todo el equipo para que el velocity siga siendo significativo con el tiempo.
Lo que el velocity NO es
Aquí es donde la mayoría de los equipos se equivocan.
El velocity no es una métrica de productividad. Un equipo con un velocity de 60 no es "mejor" que un equipo con un velocity de 30. Los story points son relativos a la propia escala de cada equipo. Un equipo podría dimensionar una funcionalidad en 8 puntos; otro podría dimensionar la misma funcionalidad en 3. No hay una unidad compartida. Comparar velocities entre equipos no tiene sentido.
El velocity no es una meta para aumentar. Cuando los managers establecen "mejorar el velocity en un 20%" como objetivo, los equipos hacen exactamente una cosa predecible: inflan sus estimaciones de story points. El número sube, pero la producción real no cambia. Solo se ha degradado la calibración del sistema de estimación.
El velocity no es una medida de desempeño individual. El velocity pertenece al equipo, no a ninguna persona en particular. Usarlo para evaluar individuos crea los incentivos equivocados y rompe la estimación colaborativa que hace precisa la métrica.
El velocity no es un compromiso. Los stakeholders a veces tratan el velocity como un piso: "Hicieron 44 puntos el sprint pasado, así que están comprometidos a al menos 44 este sprint". Así no funciona. El velocity es un promedio histórico usado para planificar, no una obligación mínima de rendimiento.
Factores que afectan el velocity
El velocity cambia con el tiempo, y la mayoría de esos cambios tienen causas evidentes. Saber qué impulsa la variación ayuda a interpretar los números en lugar de reaccionar a ellos.
Cambios en la composición del equipo. Cuando se une una persona nueva, el velocity típicamente cae durante 2 a 3 sprints mientras se pone al día. Cuando alguien se va, el efecto es inmediato. Ninguno de los dos cambios significa que el equipo esté fallando.
Días festivos y tiempo libre. Un sprint que abarca un día festivo o que tiene a varias personas de vacaciones producirá un velocity menor. Algunos equipos ajustan la capacidad del sprint en consecuencia; otros simplemente lo anotan al revisar el promedio.
Cambios de alcance a mitad de sprint. Incorporar trabajo no planificado o cambiar historias a mitad de un sprint rompe la relación entre lo que se planificó y lo que se completó. Esta es una razón por la que los límites de WIP importan: limitar el trabajo en progreso protege el sprint de interferencias a medio camino.
Desviación en la estimación. Con el paso de los meses, los equipos a veces cambian inconscientemente cómo dimensionan el trabajo. Una "historia de 5 puntos" en el primer mes podría sentirse como una "historia de 3 puntos" para el sexto mes conforme el equipo se vuelve más rápido en trabajo similar. Si el velocity tiende a subir de manera constante sin ningún cambio en el tamaño del equipo o las herramientas, verifique si las estimaciones se han desviado en lugar de asumir que el equipo genuinamente es más rápido.
Deuda técnica y fricción del entorno. Pipelines de CI lentos, incidentes frecuentes en producción y problemas de calidad de código consumen capacidad del sprint sin aparecer en el backlog. Los equipos que cargan con deuda técnica significativa suelen tener un velocity menor y más variable de lo que sugeriría su capacidad.
Velocity vs otras métricas de flujo
El velocity es una métrica a nivel de sprint. Le informa sobre el rendimiento a través de bloques de tiempo fijos. Pero no le dice todo sobre cómo fluye el trabajo a través de su sistema.
| Métrica | Qué mide | Mejor para |
|---|---|---|
| Velocity | Story points completados por sprint | Pronóstico de lanzamientos, capacidad de sprint |
| Diagrama de flujo acumulado | Conteos de elementos de trabajo a través de las etapas del workflow a lo largo del tiempo | Detectar cuellos de botella, crecimiento de WIP, estabilidad del flujo |
| Límites de WIP | Máximo de elementos concurrentes en una etapa | Optimización del rendimiento, reducción del cambio de contexto |
| Tiempo de ciclo | Tiempo desde el inicio hasta la finalización por elemento | Previsibilidad a nivel de elemento |
| Gráfico de burndown | Trabajo restante dentro de un sprint o lanzamiento | Salud del sprint en tiempo real |
El velocity y los diagramas de flujo acumulado son complementarios. El velocity le da el número de pronóstico a nivel de sprint; el CFD le muestra si su workflow es lo suficientemente saludable como para sostenerlo. Un equipo con buen velocity pero un CFD inestable (bandas de WIP crecientes, cruces frecuentes de banda) se dirige hacia una caída de velocity.
Cómo mejorar (estabilizar) el velocity
El objetivo no es maximizar el velocity. Es hacer que el velocity sea predecible, para que sus pronósticos sean confiables. Así es como se logra.
Corran sprints consistentes. Las duraciones de sprint variables (alternar entre 1 semana y 2 semanas) hacen que los datos de velocity sean incomparables. Elijan una cadencia y manténganla durante al menos 6 sprints antes de sacar conclusiones.
Completen la definición de terminado antes de cerrar historias. Si la definición de terminado de su equipo es difusa, las historias cruzan la línea de terminado en distintos niveles de calidad, haciendo que los puntos sean incomparables. Afinen la definición y hagan que se cumpla.
Protejan el sprint del trabajo no planificado. Cada incendio a mitad de sprint que aleja a un desarrollador es un golpe directo al velocity. Construyan un proceso de triaje ligero (un filtro del product owner, una regla de "romper el cristal") que canalice los elementos urgentes sin romper los compromisos del sprint.
Mantengan calibradas las estimaciones. Realicen un breve ejercicio de recalibración cada trimestre. Tomen de 5 a 10 historias completadas y vuelvan a estimarlas con el equipo actual. Si las nuevas estimaciones difieren significativamente de las originales, sus datos de velocity de antes del cambio necesitan un ajuste mental.
Rastreen las causas de los sprints atípicos. Cuando el velocity se dispara o cae más del 20% respecto al promedio móvil, anoten la causa en su retrospectiva de sprint. Los patrones se vuelven visibles: si los sprints con días festivos caen consistentemente un 25%, pueden incorporar eso en la planificación de capacidad.
Usen el refinamiento del backlog de forma consistente. Los elementos de backlog sin refinar producen estimaciones poco confiables, lo que produce un velocity ruidoso. Los equipos que refinan regularmente mantienen un velocity más estable porque trabajan a partir de historias bien comprendidas y correctamente dimensionadas.
Reduzcan la rotación de alcance. Los cambios frecuentes de alcance a mitad de sprint son el mayor impulsor individual de inestabilidad del velocity para la mayoría de los equipos. Los sprints estables con cambios de alcance mínimos producen un velocity estable.
Preguntas frecuentes
¿Cuántos sprints de datos necesito antes de que el velocity sea confiable? La mayoría de los profesionales recomienda al menos 5 a 6 sprints completados antes de tratar el velocity como un insumo de pronóstico. Antes de eso, se está observando una muestra demasiado pequeña para filtrar el ruido. Durante los primeros sprints, trate el velocity como orientativo, no predictivo.
¿Qué pasa si nuestro velocity cambia dramáticamente de un sprint a otro? Una alta varianza generalmente señala una de varias cosas: duración de sprint inconsistente, cambios frecuentes de alcance a mitad de sprint, un equipo recién cambiado, o desviación en la estimación. Comiencen por registrar la causa de cada sprint atípico en su retrospectiva. Una vez que puedan explicar la variación, pueden abordar la causa raíz en lugar de simplemente promediar alrededor del ruido.
¿Deberíamos compartir el velocity con los stakeholders? Compartan el pronóstico de lanzamiento, no el número en bruto. Los stakeholders que ven la cifra de velocity de forma aislada a menudo la tratan como una meta o un punto de referencia frente a otros equipos. El pronóstico ("este lanzamiento va en camino para el Q3 según el ritmo actual") les da lo que necesitan sin crear la presión equivocada.
¿Podemos usar el velocity sin story points? Sí. Algunos equipos rastrean el velocity en conteo de historias en lugar de puntos, lo cual funciona si sus historias son consistentemente similares en tamaño. Otros usan tallas de camiseta convertidas a una escala numérica. La clave es que cualquier unidad que usen se mantenga consistente el tiempo suficiente para construir un promedio significativo.
¿En qué se diferencia el velocity de la capacidad? La capacidad es la disponibilidad planificada (horas totales del equipo en un sprint). El velocity es el rendimiento real (puntos completados). La capacidad es el insumo; el velocity es el resultado. Los equipos a veces usan la capacidad para fijar una meta de sprint, pero usan el velocity para pronosticar lanzamientos futuros. Confundir los dos lleva a un sobrecompromiso: un sprint al 100% de capacidad no garantiza que se complete el 100% de los puntos planificados.
El velocity es un número simple, pero los equipos obtienen lo mejor de él cuando dejan de perseguirlo y comienzan a leerlo. Un velocity estable significa que sus hábitos de estimación y entrega son lo suficientemente consistentes como para planificar en torno a ellos. Cuando el velocity cambia, eso es información: algo en el entorno o proceso del equipo cambió, y vale la pena entender qué.
Combínelo con la disciplina de planificación de sprint, estimaciones limpias de story points, y visibilidad de flujo desde su diagrama de flujo acumulado, y tendrá un sistema de pronóstico en el que los stakeholders realmente pueden confiar.
Senior Operations & Growth Strategist