Cómo medir velocidad equipo Agile en 5 pasos
GestióN De Producto
Mide la velocidad de tu equipo Agile: define puntos, contabiliza sólo lo terminado, limpia sprints y usa una media móvil.
Si mido mal la velocidad, planifico mal. Yo lo resumiría así: la velocidad solo me sirve para prever cuántos puntos de historia puede cerrar el mismo equipo por sprint, y solo cuenta lo que termina según la DoD.
En este artículo, la idea central es simple: no uso la velocidad para medir personas, no comparo equipos entre sí y no meto trabajo a medias en el cálculo. Para que el dato me sirva, sigo 5 pasos: definir una escala común, contar solo lo cerrado, limpiar sprints raros, sacar una media móvil y revisar si el contexto ha cambiado.
Qué me llevo en claro:
La velocidad = puntos terminados por sprint, no horas.
Solo cuenta lo hecho al 100 % al cierre del sprint.
Un sprint con festivos, bajas o cambios de personal puede torcer la media.
La media de varios sprints suele dar una previsión más estable.
Si cambia el equipo, el stack o el backlog, la velocidad vieja puede dejar de servir.
Un dato práctico: si entra o sale gente, el texto propone descartar los 2 primeros sprints y usar 2 o 3 sprints más para fijar una nueva referencia. Es una regla simple, pero evita tomar decisiones con datos torcidos.
En pocas palabras, yo usaría esta guía para una sola cosa: planificar mejor el siguiente sprint con datos limpios y comparables.
Cómo medir la velocidad de un equipo Agile en 5 pasos
Pasos 1 y 2: define los puntos de historia y registra solo el trabajo terminado al cerrar el sprint
Paso 1: establece una escala común de puntos de historia
Los puntos de historia no miden horas. Miden esfuerzo relativo, complejidad e incertidumbre al comparar unas tareas con otras.
La forma más sencilla de empezar es escoger una tarea pequeña que el equipo conozca bien y darle un valor bajo. Esa tarea sirve como referencia para futuras estimaciones. A partir de ahí, la velocidad deja de depender de sensaciones y pasa a compararse de un sprint a otro de una forma mucho más estable.
Conviene usar una escala creciente, como Fibonacci, porque refleja bien cómo suben la complejidad y la incertidumbre cuando el trabajo se hace más grande.
Para que todo el equipo hable el mismo idioma, usa sesiones de póquer de planificación. Cada persona propone su estimación por separado y, después, se ponen en común. El equipo acuerda una única cifra. Así, cuando una historia recibe un 5, ese 5 tiene el mismo sentido para todos.
Paso 2: cierra el sprint y cuenta solo lo que está terminado
Una vez fijada la escala, el siguiente filtro está en el cierre del sprint.
Al cerrar el sprint, suma solo las historias terminadas según la DoD. Si una historia no cumple la Definición de Hecho, no cuenta. El trabajo a medias no se contabiliza.
Seguir este criterio evita inflar la velocidad y hace que los datos se puedan comparar entre sprints sin mezclar trabajo terminado con trabajo pendiente.
Pasos 3 y 4: limpia los datos del sprint y calcula la velocidad media
Paso 3: aplica los criterios de cierre y elimina los datos atípicos
Con el sprint ya cerrado, toca limpiar el histórico antes de ponerse a calcular.
Solo deben entrar las historias que cumplen todos los criterios de cierre: desarrollo, pruebas y despliegue. Si una tarea no ha pasado por todo el flujo, no cuenta. Así de simple.
También conviene sacar del cálculo, o al menos dejar marcados aparte, los sprints anómalos. Por ejemplo, los afectados por festivos, bajas o cambios de personal. Si mezclas esos casos con sprints normales, la comparación se tuerce.
Con ese histórico limpio, ya puedes medir una velocidad que tenga sentido y que se pueda comparar entre sprints.
Paso 4: calcula la velocidad del sprint y la media móvil
La velocidad de un sprint es la suma de los puntos cerrados en ese sprint limpio.
Después, calcula una media móvil con varios sprints limpios. Cuantos más sprints comparables acumules, más estable será esa media. Y eso ayuda a planificar la capacidad del equipo con más criterio. No sirve para juzgar si un sprint fue “bueno” o “malo”.
Antes de usar esa media para planificar, revisa si ha cambiado algo de fondo:
el equipo
el alcance
la tecnología
Si una de esas piezas se mueve, la media puede dejar de reflejar la situación actual.
Pero esa media solo sirve si el equipo y el contexto se han mantenido estables.
Paso 5: revisa los cambios de equipo y alcance antes de usar la velocidad en la planificación
Una vez que tengas la media móvil, toca una comprobación simple: ver si todavía sirve para planificar. La velocidad media solo ayuda cuando el contexto sigue siendo parecido. Si cambian el equipo, la tecnología o el alcance, deja de ser una referencia de fiar.
Cómo afectan los cambios de equipo a la comparabilidad de la velocidad
Cuando entra o sale gente, se mueven roles o el trabajo se reparte entre varios proyectos, la velocidad histórica se altera. Y bastante. No porque el equipo trabaje mejor o peor de golpe, sino porque el sistema ha cambiado.
Tras una incorporación, descarta los 2 primeros sprints y usa 2–3 sprints para fijar una nueva referencia estable.
Cómo afectan los cambios de alcance, tecnología o estimación a la velocidad
Aquí pasa algo parecido. Un cambio de arquitectura, la adopción de una nueva tecnología o una reestimación completa del backlog rompe la comparabilidad de la velocidad. En ese escenario, la cifra puede subir o bajar por el nuevo contexto, no por un cambio real en el ritmo del equipo.
Esta tabla resume los casos más comunes y su efecto en la comparabilidad:
Tipo de cambio | Impacto esperado en velocidad |
|---|---|
Incorporación de personas | Bajada temporal por adaptación |
Cambio de stack tecnológico | Bajada inicial por curva de aprendizaje |
Cambio de arquitectura | Bajada por foco en estabilidad |
Reestimación del backlog | Alta volatilidad |
Implementación de CI/CD | Subida a largo plazo |
Antes de planificar, revisa si los últimos sprints son comparables con el trabajo que viene. Si el contexto ya no es el mismo, usa la velocidad solo como una referencia temporal y vuelve a medir antes de planificar.
Conclusión: 5 pasos para medir la velocidad correctamente
Medir bien la velocidad pide cinco controles simples: definir una base común de puntos de historia, contar solo lo terminado, limpiar los datos, calcular la media móvil de varios sprints y revisar el contexto antes de planificar.
Con este método, la velocidad deja de ser una cifra vaga y pasa a servir para planificar de verdad. Ayuda a prever capacidad; no mide el rendimiento personal.
Si cambian el equipo, la tecnología, el alcance o la forma de estimar, la velocidad histórica deja de ser comparable. En ese caso, conviene recalcularla con un criterio estable. Solo así mantiene valor en la planificación.
FAQs
¿Cada cuánto revisar la velocidad?
Para mantener el proyecto bien afinado, revisa la velocidad del equipo de forma semanal o mensual. Así podrás detectar cambios a tiempo, hacer ajustes con agilidad y mejorar cómo avanza el trabajo.
Cuando el producto ya esté más estable, puedes espaciar esas revisiones y hacerlas de forma trimestral o anual.
¿Qué hago si el equipo cambia mucho?
Si el equipo cambia a menudo, deja las responsabilidades bien atadas. Así evitas solapamientos, malentendidos y esa típica sensación de que dos personas están tocando lo mismo sin saberlo. Una buena forma de hacerlo es asignar componentes concretos a grupos ya definidos.
También conviene documentar el onboarding. Cuanto más claro esté, antes entenderán las nuevas incorporaciones la visión del producto, cómo se trabaja y qué se espera de ellas. Eso ahorra tiempo desde el primer día.
Por otro lado, mantener metodologías ágiles ayuda a ajustar el rumbo cuando hace falta, sin perder de vista la calidad del código ni la escalabilidad.
¿Cuántos sprints necesito para estimar bien?
No existe un número mágico, pero la estabilidad suele llegar después de tres a cinco sprints. Ese margen le da al equipo tiempo para ajustar su ritmo de entrega y reunir datos suficientes para que la media de puntos por sprint tenga sentido.
Para que la estimación resulte fiable, hay dos cosas que importan mucho: mantener la consistencia al definir las tareas y cerrar los ciclos siempre del mismo modo.