La velocidad del equipo en metodologías ágiles: cómo medirla y aprovecharla (+ calculadora gratuita)

La velocidad del equipo es un dato de referencia para las previsiones, no un indicador clave de rendimiento (KPI). En el momento en que se evalúa a los equipos en función de este indicador, los resultados se inflan.

La velocidad es el número medio de puntos de historia que un equipo completa por sprint, calculado a partir de los últimos sprints. Esa es toda la definición. Su única finalidad es proyectar cuántos sprints se necesitarán para entregar el backlog, teniendo en cuenta el ritmo real de entrega del equipo. Sume los puntos restantes, divídalos entre la velocidad y obtendrá una previsión. Sinceramente, eso es lo único que hace.

Cualquier otro uso lo desvirtúa. «¿Por qué ha sido menor la velocidad en este sprint?» convierte cada retrospectiva en una defensa de la cifra. «El equipo A tiene una velocidad mayor que el equipo B» trata las calibraciones independientes de ambos equipos como si fueran comparables, cuando no lo son. «Tenemos que aumentar la velocidad un 20 % este trimestre» indica al equipo que debe hacer que la cifra suba, y el equipo lo hará, sobrevalorando el mismo volumen de trabajo en lugar de realizar más. Esa es la ley de Goodhart aplicada a un ciclo de dos semanas.

Una advertencia sincera antes de pasar a las instrucciones: el Guía de Scrum No hace referencia a la velocidad. Se trata de una práctica habitual que se aplica como complemento de Scrum, no de una regla del mismo, y precisamente por eso conviene reflexionar detenidamente sobre el fin para el que se utiliza.

Cómo calcular la velocidad del equipo

Tome los puntos obtenidos en cada uno de los últimos tres a cinco sprints. Calcule la media. Esa es su velocidad.

Un ejemplo práctico, a lo largo de tres sprints:

Sprint	Puntos de historia completados
Sprint 7	21
Sprint 8	34
Sprint 9	26

Velocidad = (21 + 34 + 26) dividido entre 3 = 27 puntos por sprint.

Si la cartera de trabajo tiene 210 puntos restantes, la previsión es de 210 dividido entre 27, lo que equivale a unos 8 sprints. Dado que los valores introducidos oscilaban entre 21 y 34, la estimación más realista es «entre siete y diez sprints», y no «7,8 sprints». O bien, prescinda de los cálculos y deje que la calculadora anterior lo haga por usted.

Las reglas que garantizan la veracidad de la cifra: no se deben realizar ajustes por sprints «excepcionales», ya que estos forman parte de la señal que se está intentando suavizar. No cuente dos veces el trabajo arrastrado, y no cuente en absoluto las historias parcialmente completadas. Estas se contabilizan en el sprint en el que realmente se finalizan. Cuanto más sencillo es el cálculo, más difícil resulta manipularlo.

La velocidad se estabiliza una vez que un equipo lleva trabajando en conjunto durante tres o cuatro sprints. Un nuevo equipo, una nueva historia de referencia o un cambio importante en la plantilla son motivos para descartar la cifra anterior y empezar de cero. La cifra no es una característica de la técnica. Es una característica de este equipo en este periodo de tiempo. Un equipo que ayer perdió a dos miembros tiene la velocidad de ayer, pero corresponde a un equipo diferente.

Utilizar la velocidad para planificar el próximo sprint

Velocity demuestra su utilidad en la planificación de sprints, y el método es breve:

1. Parta de la media móvil de los últimos tres a cinco sprints; nunca utilice el resultado de un solo sprint, ni tampoco su mejor sprint.
2. Tenga en cuenta los cambios conocidos en la capacidad. ¿Dos personas de baja en el próximo sprint? ¿Un día festivo? Reduzca el objetivo de forma proporcional antes de planificar, no a regañadientes después. La velocidad se calcula en función del equipo que la ha generado, y el equipo del próximo sprint a veces es más reducido.
3. Asigne un porcentaje inferior a la media, entre el 80 % y el 90 % aproximadamente. Seleccione las tareas hasta que su suma se acerque a ese porcentaje y deje un margen para el trabajo imprevisto que surge en cada sprint, independientemente de si lo ha previsto o no.
4. Realice previsiones en forma de intervalos. Para cualquier plazo que vaya más allá del próximo sprint, indique sus mejores y peores sprints recientes como límites. Las partes interesadas pueden planificar en torno a «entre siete y diez sprints». No pueden planificar en función de una cifra exacta que luego resulte ser errónea.

Utilice la velocidad para hacer tres cosas, y solo tres: estimar una fecha para un alcance conocido (el alcance dividido por la velocidad da como resultado el número de sprints), decidir qué cabe en el próximo sprint y detectar cuándo algo ha cambiado (una caída del 30 % es una señal que merece una conversación en la retrospectiva). Lo que no puede hacer con ella: compararla con las cifras de otro equipo, utilizarla para calificar al equipo o convertirla en «horas previstas por desarrollador al día». Cada una de estas acciones constituye el mismo error con un nombre diferente.

¿Cuántos puntos de historia por sprint?

Buscar «cuántos puntos de historia por sprint» es un error de categoría. No existe una cifra estándar del sector, ni una cifra «adecuada», ni una tasa por desarrollador y día. La velocidad es el rendimiento medido del equipo, y la única versión útil es la media móvil de los últimos sprints del propio equipo. Quince puntos, cuarenta puntos, cien puntos… Ninguna cifra es correcta o incorrecta. Todas ellas se calibran en función de la historia de referencia del equipo.

El gran error: la velocidad como indicador de rendimiento

El modo de fallo más habitual: un responsable interpreta la cifra de velocidad como «¿qué nivel de productividad tiene este equipo?». Se menciona en las reuniones de estado, se compara entre equipos y, a continuación, se convierte en un objetivo. En el plazo de dos sprints, el equipo ha reajustado el tamaño de sus historias para que la cifra aumente; ahora, cada historia tiene un tamaño un 30 % mayor que antes, y la velocidad ha dejado de significar lo que solía significar. La previsión que se suponía que debía generar ahora es errónea.

El segundo: la comparación entre equipos. Dos equipos que evalúan el mismo backlog obtienen cifras de velocidad diferentes porque utilizan historias de referencia distintas, y ahí radica precisamente la esencia de la estimación relativa. Compararlas es como comparar dos termómetros con puntos cero diferentes. Las cifras no significan lo mismo, y tratarlas como si lo hicieran altera la calibración de ambos equipos.

¿Prefiere que le hagamos los cálculos? Vuelva a la calculadora de velocidad gratuita y pruebe sus propios sprints con ella.

Cuándo volver a realizar una estimación

La reestimación del trabajo ya completado frena la velocidad. La reestimación del trabajo pendiente es el único caso en el que se actúa con honestidad.

Cada trimestre surge la misma pregunta: «Lo valoramos como un 5, pero en realidad era un 13, ¿deberíamos actualizarlo?». El instinto que dice que sí es el mismo que quiere que todas las cifras sean correctas con carácter retroactivo, y está equivocado. La velocidad es el ritmo al que el equipo, con la calibración que tenía en ese momento, completó el trabajo. Volver atrás y reescribir los puntos también reescribe la calibración, y la previsión que antes funcionaba deja de hacerlo. «El equipo se ha vuelto más rápido, por lo que las historias antiguas deberían ser más pequeñas» elimina la única señal de que el equipo ha mejorado. «Este 5 resultó ser un 13» es una señal de refinamiento para dimensionar la siguiente historia similar, no una licencia para reescribir el historial de esta.

El único caso en el que debe volver a realizar una estimación es el de los trabajos aplazados. Una historia no se ha completado, el sprint está a punto de finalizar y el trabajo restante pasa a formar parte del compromiso del siguiente sprint. Ese trabajo restante difiere sustancialmente de lo que se había calculado al principio: el equipo ha completado parte de él, ha detectado al menos un imprevisto y tiene una visión más clara de lo que queda por hacer. Vótelo de nuevo como si fuera nuevo, utilizando la estimación original como referencia para verificar la viabilidad, en lugar de como una restricción.

Normalización de la velocidad entre equipos

La normalización es, en su mayor parte, un ritual de SAFe destinado a que los datos del panel de control de la cartera cuadren. No lo haga, a menos que alguien de su jerarquía superior necesite realmente ese panel de control.

La normalización consigue que dos o más equipos se pongan de acuerdo en una referencia común, normalmente algo así como «un día-persona de trabajo para un ingeniero medio», de modo que un 5 en el Equipo A signifique lo mismo que un 5 en el Equipo B, y se puedan sumar sus velocidades. La técnica funciona: un 5 normalizado realmente significa lo mismo para todos los equipos que lo han acordado. El problema radica en lo que se ha sacrificado a cambio. Ha cambiado la propiedad de estimación relativa de cada equipo por una absoluta, lo que equivale a una estimación de la duración encubierta, solo para poder calcular la media de un número entre equipos que no comparten una base de código, una pila tecnológica ni un dominio.

Si una previsión a nivel de cartera financia realmente el trabajo (y no se limita a comparar equipos), realice la normalización en la capa de agregación: haga que la gestión del programa mantenga un multiplicador de puntos por equipo, calibrado una sola vez y revisado en contadas ocasiones, y aplíquelo cuando se agreguen las cifras. Cada equipo seguirá realizando sus estimaciones en función de su propia historia de referencia; el multiplicador convierte la velocidad del equipo en la unidad de medida de la cartera, y las reuniones de refinamiento nunca lo tienen en cuenta. A qué hay que oponerse: a la normalización que se inicia dentro de un único equipo y a la normalización realizada con el fin de facilitar la comparación entre equipos. Esta última no es un caso de uso, sino un antipatrón con un nombre elegante.

Herramientas de programación de Velocity y de inteligencia artificial

Copilot, Cursor, Claude Code. Los puntos no cambian. La velocidad sí, y solo a posteriori.

La pregunta surge en todos los equipos que llevan unos meses utilizando un asistente de programación basado en IA: estamos lanzando productos más rápido, ¿deberíamos reajustar el backlog? ¿Debería el 3 del último trimestre convertirse en un 5 este trimestre? La respuesta es no, porque los puntos de historia nunca han medido lo que ha cambiado. Los puntos miden la complejidad relativa y la incertidumbre; el asistente reduce el tiempo de escritura de una historia, a veces de forma drástica, pero la complejidad no varía, las incógnitas no varían, el riesgo de integración y los casos extremos tampoco varían. No rebaje un 5 a un 3 solo porque la herramienta haya escrito el código repetitivo y usted vuelva a estimar en horas.

Lo que cambia es la velocidad. El mismo equipo que entrega el mismo tipo de trabajo con la ayuda de un asistente entrega más puntos por sprint que hace seis meses, no porque los puntos sean más pequeños, sino porque el equipo se ha vuelto más rápido a la hora de convertir los puntos en código entregado. Esa cifra cumple exactamente su función y se reajusta de forma natural a lo largo de tres o cuatro sprints. Mantenga actualizada la historia de referencia del equipo, una que se haya entregado con las herramientas que utilizan actualmente, y la calibración ya tendrá en cuenta cualquier aumento de velocidad que exista.

Hay dos aspectos que hay que rebatir. La afirmación «La velocidad ha aumentado un 30 %, comprometámonos a un 30 % más» cuenta por duplicado la mejora: la media reciente ya incluye el efecto de la IA, por lo que no debe volver a escalarse. «Todo se ha reducido, volvamos a estimar el backlog» es la trampa de la reestimación mencionada anteriormente: las historias no se han reducido, el equipo se ha vuelto más rápido y la previsión ya lo refleja. La incertidumbre es el ámbito en el que las herramientas son menos útiles: un asistente agiliza partes de la investigación de un spike, pero lo que el spike intenta averiguar no se ha reducido en absoluto.

Realicen la estimación de forma conjunta en TeamRetro

La precisión de Velocity depende de la calidad de las estimaciones en las que se basa. TeamRetro Estimaciones lleva a cabo una sesión de «planning poker» con su equipo, ya sea en directo o de forma asíncrona, por lo que los puntos que introduzca en esta calculadora provienen del criterio de todo el equipo, y no de la suposición de una sola persona. Pruebe TeamRetro Estimations o comience con la herramienta gratuita de «planning poker».

Preguntas frecuentes

¿Qué es la velocidad del equipo en el método ágil?

La velocidad del equipo es el número medio de puntos de historia que un equipo completa por sprint, y suele medirse a lo largo de los últimos tres a cinco sprints. Se trata de un dato de referencia para la planificación, que se utiliza para prever cuánto trabajo cabe en el próximo sprint y cuánto tiempo llevará completar la cartera de tareas, y no es un indicador del rendimiento del equipo.

¿Cómo se calcula la velocidad de un equipo?

Sume los puntos de historia completados en cada uno de los últimos tres a cinco sprints y calcule la media. Si en sus últimos tres sprints se completaron 21, 34 y 26 puntos, su velocidad es de 27. Cuente únicamente las historias finalizadas en el sprint en el que se completaron, o utilice la calculadora gratuita de esta página para realizar los cálculos.

¿Cuál es una buena velocidad de equipo?

Una velocidad estable. No existe un punto de referencia, ya que los puntos de cada equipo se ajustan a su propio historial de referencia, por lo que tanto 15 como 40 y 100 pueden ser valores adecuados. Una buena velocidad es aquella con la que se puede planificar, no una cifra que no deja de aumentar.

¿Debería comparar la velocidad entre los distintos equipos?

No. Los distintos equipos calibran los puntos en función de historias de referencia diferentes, por lo que sus velocidades no se expresan en las mismas unidades. Compararlas es como comparar dos termómetros con puntos cero distintos. Además, la comparación entre equipos ejerce presión sobre estos para que inflen sus estimaciones, lo que distorsiona las previsiones que la velocidad pretende generar.

¿Y si no utilizamos puntos para la estimación, sino, por ejemplo, las tallas de camiseta?

Aún así, puede realizar un seguimiento aproximado del rendimiento, pero no puede obtener una cifra real de la velocidad directamente a partir de las tallas de camiseta, ya que estas no son sumables. Hay dos opciones. En primer lugar, asigne a las tallas una escala simple de puntos (por ejemplo, XS = 1, S = 2, M = 3, L = 5, XL = 8), sume los artículos completados en cada sprint y considere el resultado como una tendencia aproximada, más que como una cifra precisa. O bien, si sus elementos suelen tener un tamaño similar, cuente en su lugar el rendimiento: el número de elementos finalizados por sprint. Ambas opciones son menos precisas que la velocidad basada en puntos, por lo que debe interpretarlas como una orientación general, no como decimales. Cuando necesite una previsión real, vuelva a estimar el trabajo a corto plazo en puntos. Consulte nuestra guía sobre tallas de camiseta para conocer la correspondencia entre tallas y puntos.

¿Cómo se contabiliza el trabajo que no se registra como partidas cuantificadas?

La velocidad solo refleja el trabajo que realmente cuantifica y supervisa. Las incidencias de soporte, las reuniones, las interrupciones y las correcciones de errores no asignadas a puntos siguen consumiendo capacidad; por lo tanto, si gran parte de ese trabajo es invisible, su velocidad parecerá inferior al esfuerzo real del equipo y sus previsiones resultarán demasiado optimistas. Dos soluciones sinceras. Registre el trabajo recurrente no planificado como elementos cuantificados para que se incluya en la velocidad al igual que el resto. O bien, reserve capacidad para ello de forma abierta, comprometiéndose a dedicar entre el 80 y el 90 por ciento de su media y dejando el resto como Slack. No asigne puntos a posteriori al trabajo invisible solo para que la cifra parezca mayor, ya que eso altera la calibración de la que depende la velocidad.

¿Cómo se gestiona el trabajo de corrección en Velocity?

El trabajo de reelaboración supone un esfuerzo real, pero volver a puntuar una historia que ya se había contabilizado como finalizada afecta negativamente a la velocidad. Trate el trabajo de reelaboración como si fuera un trabajo nuevo: cree una nueva tarea, evalúe su tamaño y contabilícela en el sprint en el que se complete. No vuelva a abrir la historia original ni la reevalúe. Si el trabajo de revisión sigue apareciendo, se trata de una señal de calidad que merece una conversación en la retrospectiva, no un ajuste de la velocidad. La previsión solo es fiable si cada punto se cuenta una sola vez, en el sprint en el que el trabajo se ha completado realmente.

¿Cuántos puntos de historia por sprint se consideran normales?

No existe una cifra estándar en el sector. La velocidad es el rendimiento medido de su equipo, es decir, la media móvil de los puntos completados en los últimos sprints. Quince, cuarenta, cien: ninguna cifra es correcta o incorrecta, ya que cada una se ajusta a una historia de referencia diferente.

¿Cuántos puntos de historia por sprint por desarrollador?

No lo calcule por separado. Una tarifa por desarrollador convierte los puntos de historia de nuevo en horas encubiertas y da pie a la comparación entre personas, algo que esta técnica pretende evitar. La velocidad es una cifra del equipo, no la suma de las cuotas individuales.

¿Cuántos puntos de historia hay en un sprint de dos semanas?

Sea cual sea el número de historias que su equipo haya completado históricamente en un sprint de dos semanas, mídalo, pero no lo utilice como objetivo. Seleccione historias hasta que su suma alcance aproximadamente entre el 80 % y el 90 % de su media reciente, y deje margen para lo imprevisto.

¿Cuál es una buena velocidad para un equipo de Scrum?

Una que sea estable. «¿Es buena nuestra velocidad?» es la pregunta que desestabiliza el sistema. En el momento en que se califica la velocidad, los puntos se inflan y, en realidad, nada se entrega más rápido. Una buena velocidad es aquella con la que se puede planificar, no una cifra que no deja de subir.

Lecturas relacionadas

• Puntos de historia frente a horas: por qué la conversión de puntos a horas es el modo de fallo que sustituye a la velocidad.
• Planificación de la velocidad y la capacidad: utilizar la velocidad para determinar un compromiso realista para el sprint.
• ¿Qué es un gráfico de burndown?: cómo los equipos realizan un seguimiento de los puntos a los que se han comprometido en un sprint.
• Técnicas de estimación ágil: dónde encaja la «velocidad» entre el «planning poker», los «puntos de historia» y el resto, y cuál utilizar en cada caso.
• Guía de estimación ágil: el conjunto completo de métodos de estimación.
• Planning Poker gratuito para equipos ágiles: calcule los puntos a partir de los cuales se calcula la velocidad.