Velocidad: para qué sirve y cómo calcularla

La velocidad es un dato de referencia para las previsiones, no un indicador clave de rendimiento (KPI). En cuanto se utiliza para evaluar a los equipos, se exagera.

La velocidad es el número medio de puntos de historia que un equipo completa por sprint a lo largo 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. Si se suman los puntos restantes y se dividen por la velocidad, se obtiene 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» le indica al equipo que haga que la cifra suba, y el equipo lo hará —sobrevalorando el mismo volumen de trabajo, no realizando más—. La ley de Goodhart, aplicada en un ciclo de dos semanas.

Cómo calcularlo

Tome los puntos completados en cada uno de los últimos tres a cinco sprints. Calcule la media. Esa es su velocidad. No realice ajustes por sprints «excepcionales»: los sprints excepcionales forman parte de la señal que está intentando suavizar. No cuente dos veces el trabajo arrastrado. No cuente en absoluto las historias parcialmente completadas; estas se contabilizan en el sprint en el que realmente se terminan. Cuanto más sencillo sea el cálculo, más difícil resultará 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, un cambio importante en la plantilla: todas ellas son razones para descartar la cifra anterior y empezar de cero. La cifra no es una propiedad de la técnica; es una propiedad 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.

¿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 (velocity) 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. Se calibran en función de la historia de referencia del equipo.

Por lo tanto, utilice la velocidad para hacer tres cosas, y solo tres: calcular una fecha para un alcance conocido (alcance ÷ velocidad = número de sprints); decidir qué cabe en el próximo sprint (seleccione historias hasta que su suma alcance aproximadamente el 80-90 % de la media reciente, dejando margen para lo imprevisto); 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 es el mismo error con un nombre diferente.

¿Qué es lo que falla?

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 —cada historia tiene ahora 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; en eso consiste precisamente 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.

Cuándo volver a realizar una estimación

La reestimación del trabajo ya completado frena el ritmo de avance. 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 valorar 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 sus velocidades puedan sumarse. La técnica funciona: un 5 normalizado realmente significa lo mismo en todos los equipos que lo han acordado. El problema es 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 tienen en cuenta este factor. 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í lo hace, 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 tamaño del backlog? ¿Debería el 3 del último trimestre ser 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 cambie un 5 por 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 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/guides/agile-estimation-guide/what-are-story-points/ 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» contabiliza dos veces la mejora: la media reciente ya incluye el efecto de la IA, por lo que no debe volver a multiplicarse. «Todo se ha reducido, reestimemos 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 donde 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.

Preguntas frecuentes

¿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: 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?

Independientemente del 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 el 80-90 % de su media reciente, y deje margen para lo imprevisto.

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

Una que sea estable. «¿Es buena nuestra velocidad?» es la pregunta que desestabiliza el sistema: en el momento en que se evalúa 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 aumentar.

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.
• Guía de estimación ágil — el conjunto completo de recursos sobre estimación.
• Planning Poker gratuito para equipos ágiles — calcule los puntos en los que se basa la velocidad.