La velocidad (desarrollo de software) es la herramienta de previsión más sencilla del trabajo ágil: se suma el trabajo que un equipo terminó en un sprint, se promedia a lo largo de varios sprints y se sabe aproximadamente cuánto podrá asumir el equipo la próxima vez. La idea procede de Extreme Programming y hoy es habitual en Scrum y en otros marcos iterativos, pero también es una de las cifras peor utilizadas en la gestión de ingeniería.
Bien utilizada, la velocidad convierte una reunión de planificación en una conversación breve y basada en datos. Los problemas empiezan cuando alguien la convierte en un objetivo: las estimaciones se inflan y, al cabo de uno o dos trimestres, la cifra apenas significa nada. Las empresas que contratan servicios de product engineering orientados a resultados suelen ver la velocidad junto a las métricas de entrega y de producto, no de forma aislada, porque una velocidad estable no dice si el trabajo entregado movió un KPI de negocio.
A continuación encontrará la fórmula con un ejemplo calculado de seis sprints, una previsión de entrega que puede reutilizar, una comparación de la velocidad con la capacidad, el throughput y las métricas DORA, y los errores que convierten la velocidad en una métrica de vanidad, incluidos los nuevos que traen en 2026 las herramientas de programación con IA.
¿Qué es la velocidad en el desarrollo de software?
La velocidad en el desarrollo de software es la cantidad de trabajo que un equipo ágil completa durante una iteración, medida en las mismas unidades relativas que el equipo usa para estimar, casi siempre story points (estimaciones relativas de esfuerzo, complejidad e incertidumbre en lugar de horas). Solo cuenta el trabajo que cumple la Definition of Done del equipo, la lista de comprobación compartida que indica cuándo un elemento está realmente terminado, y la cifra se usa para prever cuánto podrá completar ese mismo equipo en futuras iteraciones.
La velocidad es una medida empírica: registra lo que ocurrió en lugar de predecir lo que debería ocurrir. El valor de la velocidad está en la tendencia a lo largo de varios sprints, no en un sprint aislado. Un equipo que completó 30, 34 y 32 puntos en sus tres últimos sprints de dos semanas tiene una velocidad de unos 32 puntos por sprint, y esa cifra solo tiene sentido para ese equipo, con su escala de estimación, su base de código y su Definition of Done.
El concepto apareció a finales de la década de 1990 en Extreme Programming, donde los equipos usaban la cantidad de trabajo terminada en la última iteración («yesterday’s weather», el tiempo de ayer) para planificar la siguiente. El libro de Mike Cohn Agile Estimating and Planning popularizó después la velocidad junto con los story points. La Scrum Guide oficial no exige la velocidad en absoluto; solo indica que el rendimiento pasado y la capacidad del equipo orientan la cantidad de trabajo que se selecciona en el Sprint Planning.
Velocidad del sprint frente a velocidad del equipo
La velocidad del sprint es el número de puntos completados en un sprint concreto, mientras que la velocidad del equipo es la media de varios sprints recientes. La velocidad del sprint es un dato; la velocidad del equipo es la cifra de planificación. Planificar a partir de un solo sprint es arriesgado, porque un sprint puede verse distorsionado por unas vacaciones, una incidencia en producción o una historia inusualmente grande que se termina el último día.
¿Qué unidades se pueden usar para medir la velocidad?
Los story points son la unidad de velocidad más habitual, pero sirve cualquier unidad coherente de trabajo completado. La elección importa menos que mantenerla estable en el tiempo.
- Story points: estimaciones relativas de esfuerzo, complejidad e incertidumbre, a menudo en una escala de tipo Fibonacci (1, 2, 3, 5, 8, 13).
- Días u horas ideales: estimaciones de esfuerzo sin interrupciones, más fáciles de explicar a los stakeholders, pero que se interpretan con más facilidad como compromisos de plazo.
- Número de elementos: historias o tickets completados por sprint, algo que funciona bien cuando el trabajo se divide en elementos de tamaño similar.
- Tallas de camiseta convertidas en números: S, M y L asociadas a valores fijos, un término medio para equipos que empiezan a estimar.
Contar elementos en lugar de puntos elimina el ritual de la estimación y se comporta como un throughput. Solo funciona si el equipo divide el trabajo de forma sistemática en piezas pequeñas y comparables.
¿Cómo se calcula la velocidad en el desarrollo de software ágil?
Para calcular la velocidad en el desarrollo de software ágil, sume los story points de todos los elementos que cumplieron la Definition of Done en un sprint y, después, promedie ese total a lo largo de los últimos tres a cinco sprints de igual duración. La fórmula es: velocidad = suma de los story points completados en los sprints considerados ÷ número de sprints considerados.
- Fije la duración del sprint. Use iteraciones de la misma duración, por ejemplo de dos semanas; si no, los sprints no son comparables.
- Cuente solo el trabajo terminado. Un elemento cuenta cuando cumple la Definition of Done: programado, revisado, probado y aceptado. Los elementos terminados a medias cuentan como cero.
- Sume los puntos de cada sprint. Sume las estimaciones de todos los elementos completados; ese total es la velocidad del sprint.
- Promedie varios sprints. Calcule una media móvil de los últimos tres a cinco sprints para suavizar el ruido.
- Comunique un rango, no una única cifra. Anote el valor reciente más bajo y el más alto junto a la media, porque es la dispersión lo que hace honestas las previsiones.
La tabla siguiente muestra un ejemplo calculado para un equipo de cinco ingenieros que trabaja en sprints de dos semanas.
| Sprint | Puntos comprometidos | Puntos completados (velocidad) | Notas |
|---|---|---|---|
| Sprint 1 | 34 | 26 | Equipo nuevo, estimación todavía en ajuste |
| Sprint 2 | 30 | 31 | Sprint estable |
| Sprint 3 | 32 | 29 | Un ingeniero de vacaciones durante tres días |
| Sprint 4 | 32 | 35 | Historia grande terminada el último día |
| Sprint 5 | 33 | 21 | Una incidencia en producción ocupó dos días |
| Sprint 6 | 32 | 33 | Sprint estable |
Una media móvil de los tres últimos sprints (35, 21 y 33) da una velocidad de unos 30 puntos. En los seis sprints, la media es de 29 puntos, con un rango de 21 a 35. Para planificar, este equipo debería esperar unos 29–31 puntos en un sprint normal y considerar improbable cualquier valor por encima de 35 si no cambia el equipo o el trabajo.
¿Cuentan los story points sin terminar en la velocidad?
No, los story points sin terminar no cuentan en la velocidad. Si una historia está terminada al 90% al final del sprint, aporta cero puntos a ese sprint y su estimación completa cuenta en el sprint en que se termina. Repartir los puntos para «reconocer» el trabajo parcial oculta el problema real, que suele ser una historia demasiado grande o un sprint sobrecargado. Volver a estimar las historias arrastradas es opcional; muchos equipos mantienen la estimación original para evitar la inflación.
¿Deben contar los bugs y la deuda técnica en la velocidad?
Los bugs y el trabajo de deuda técnica solo deben contar en la velocidad si el equipo los estima en puntos antes del sprint, igual que las historias. Si se excluye la corrección de bugs no planificada, la velocidad baja cuando la calidad es mala, y eso es información útil. La regla importante es la coherencia: decida una sola vez cómo trata el equipo los bugs, los spikes y el mantenimiento, y mantenga esa regla estable para que la tendencia siga siendo comparable.
¿Qué necesita para medir la velocidad con precisión?
Para medir la velocidad con precisión se necesita un equipo estable, una duración de sprint fija, una Definition of Done estricta y una práctica de estimación coherente. Cuando cambia cualquiera de estas cuatro condiciones, la velocidad pasada se convierte en un mal predictor del trabajo futuro.
- Un equipo estable. Añadir o retirar personas cambia la velocidad, a menudo durante varios sprints. Los nuevos miembros primero ralentizan al equipo mientras se incorporan.
- Duración de sprint constante. Los sprints de dos semanas no se pueden comparar con los de tres semanas sin normalizar.
- Una Definition of Done sólida. Si «terminado» significa unas veces «fusionado» y otras «en producción», la velocidad deriva por motivos que no tienen nada que ver con el trabajo real.
- Una práctica de estimación coherente. Las mismas historias de referencia y las mismas personas estimando mantienen los puntos comparables en el tiempo.
- Una herramienta de seguimiento fiable. Jira, Azure DevOps, Linear o una herramienta similar debe registrar con exactitud los cambios de estado; de lo contrario, los datos quedan incompletos.
Si su equipo estima en horas o días en lugar de puntos, se aplica la misma lógica. Nuestra guía de estimación de proyectos de software compara los story points, la estimación de tres puntos y otras técnicas que alimentan una planificación basada en la velocidad.
¿Cómo usan los equipos la velocidad para planificar sprints y entregas?
Los equipos usan la velocidad como uno de los datos para decidir cuánto trabajo incluir en el siguiente sprint y para prever cuándo se terminará un backlog de tamaño conocido. La velocidad orienta la decisión, pero no la toma. El equipo se sigue comprometiendo en función de quién está realmente disponible, de lo que más importa en ese momento y de lo que podría salir mal en ese sprint concreto.
Cómo fijar un objetivo de sprint a partir de la velocidad
En el Sprint Planning, parta de la velocidad media y ajústela según los cambios de capacidad conocidos. Si el equipo hace de media 30 puntos y uno de los cinco ingenieros va a faltar la mitad del sprint, un objetivo realista ronda los 27 puntos. Festivos, guardias, incorporaciones y talleres previstos reducen la capacidad y deben restarse antes de que el equipo se comprometa.
La guía de Scrum en el desarrollo de software describe cómo encajan el Sprint Planning, el Sprint Goal y el Sprint Backlog; la velocidad simplemente mantiene el alcance elegido dentro de lo que el equipo ha demostrado que puede terminar.
Prever una entrega con un rango
Para prever una entrega, divida el backlog restante entre la velocidad baja y la velocidad alta del equipo y obtendrá un rango de fechas en lugar de una sola fecha. Para un backlog de entrega de 240 puntos y una velocidad de entre 26 y 34 puntos por sprint:
- Caso optimista: 240 ÷ 34 ≈ 7 sprints.
- Caso pesimista: 240 ÷ 26 ≈ 9,2, es decir, 10 sprints.
- Conversión a calendario: con sprints de dos semanas, la previsión es de 14 a 20 semanas.
- Añada un margen para el crecimiento del alcance. Los backlogs suelen crecer durante la entrega a medida que el equipo aprende; haga un seguimiento separado de los cambios de alcance para que sigan siendo visibles.
- Rehaga la previsión en cada sprint. Actualice el rango con cada nuevo dato en lugar de defender la primera estimación.
- Use previsiones probabilísticas para las entregas grandes. Una simulación de Montecarlo, que reproduce miles de escenarios posibles a partir de su velocidad o su throughput históricos, da respuestas como «85% de probabilidad antes de la semana 18», más honestas que una sola fecha.
¿Qué diferencia hay entre velocidad, capacidad, throughput y productividad?
La velocidad mide el trabajo completado por sprint, la capacidad mide el tiempo de trabajo disponible, el throughput cuenta los elementos terminados por periodo y la productividad relaciona el resultado con el valor y el esfuerzo. Responden a preguntas distintas y es fácil confundirlas, lo que lleva a malas decisiones.
| Métrica | Qué mide | Unidad | Mejor uso | Principal limitación |
|---|---|---|---|---|
| Velocidad | Trabajo estimado completado por sprint | Story points o elementos por sprint | Alcance del sprint y previsiones de entrega para un equipo | No comparable entre equipos; fácil de inflar |
| Capacidad | Tiempo de trabajo disponible en un sprint | Días-persona u horas | Ajustar el objetivo del sprint a vacaciones y otras tareas | No indica cuánto trabajo cabe en ese tiempo |
| Throughput | Número de elementos terminados por periodo de tiempo | Elementos por semana o por sprint | Previsiones basadas en el flujo, equipos Kanban | Requiere elementos de trabajo de tamaño parecido |
| Tiempo de ciclo | Tiempo desde el inicio hasta el final de un elemento | Días | Detectar cuellos de botella y trabajo que se alarga | No muestra el resultado total |
| Productividad | Valor entregado en relación con el esfuerzo o el coste | Variable (resultados, DORA, SPACE) | Decisiones de gestión y de inversión | Difícil de medir; no hay una única cifra |
Los equipos que trabajan con un flujo continuo en lugar de sprints rara vez miden la velocidad y se apoyan en el throughput, el tiempo de ciclo y los límites de trabajo en curso; la guía de Kanban en el desarrollo de software explica ese modelo. Para una visión más amplia de la medición más allá del sprint, consulte nuestro artículo sobre la productividad en el desarrollo de software.
¿Qué influye en la velocidad del desarrollo de software?
La velocidad del desarrollo de software depende sobre todo de la estabilidad del equipo, del tamaño del trabajo, de las interrupciones, de la deuda técnica y de la calidad del pipeline de entrega, no de lo mucho que trabajen las personas. Conocer estos factores ayuda a explicar una caída antes de que alguien empiece a pedir al equipo que «vaya más rápido».
- Composición y cambios del equipo. Las nuevas incorporaciones, las salidas y los ingenieros compartidos entre equipos hacen variar la velocidad.
- Tamaño y claridad de las historias. Las historias grandes y vagas se arrastran de un sprint a otro y vuelven inestable la velocidad.
- Trabajo no planificado. Las incidencias en producción, las peticiones urgentes de soporte y las solicitudes puntuales de los stakeholders consumen capacidad.
- Deuda técnica y salud del código. El código frágil, la falta de pruebas y las dependencias complejas ralentizan cada cambio.
- Flujo de revisión y despliegue. Las colas largas de revisión de código, las pruebas manuales y los pipelines de CI lentos retrasan el momento en que el trabajo está «terminado».
- Dependencias externas. Esperar a otro equipo, a la API de un proveedor o a una aprobación de seguridad bloquea un trabajo que, por lo demás, está acabado.
- Trabajo en curso. Empezar muchos elementos a la vez dispersa la atención y hace que se terminen menos.
La complejidad de las tareas merece un análisis aparte, porque el mismo número de puntos puede esconder niveles de riesgo muy distintos. Nuestra guía de métricas de complejidad de tareas en el desarrollo de software recoge medidas cognitivas y de código que explican por qué algunos sprints se atascan.
Velocidad ágil frente a developer velocity: ¿cuál es la diferencia?
La velocidad ágil es una cifra de planificación del equipo expresada en story points, mientras que la «developer velocity» es un término de gestión más amplio que describe con qué rapidez una organización de ingeniería convierte ideas en software que funciona. Ambas comparten una palabra, pero responden a preguntas distintas.
El término developer velocity se popularizó con la investigación de McKinsey sobre el Developer Velocity Index de 2020, que relacionaba prácticas de ingeniería sólidas, como las herramientas, la gestión de producto y la cultura, con el rendimiento empresarial. La investigación de McKinsey concluyó que las empresas del cuartil superior del índice aumentaron sus ingresos entre cuatro y cinco veces más rápido que las del cuartil inferior. En ese sentido, la developer velocity trata de capacidades y entorno, no de puntos de sprint.
Para medir el rendimiento de entrega de toda la organización, la mayoría de los equipos utilizan en 2026 las métricas DORA publicadas por el programa DevOps Research and Assessment de Google: frecuencia de despliegue, lead time de los cambios, tasa de fallos de cambios y tiempo de restauración del servicio. Las métricas de flujo, como el tiempo de ciclo y el trabajo en curso, completan el cuadro. La velocidad puede convivir con ellas como ayuda de planificación del equipo, pero no debe sustituirlas. Nuestra lista de KPI del desarrollo de software muestra cómo encajan estas métricas.
¿Cuáles son los errores más frecuentes con la velocidad?
El error más frecuente con la velocidad es tratarla como un objetivo de rendimiento, lo que infla rápidamente las estimaciones y destruye su valor para la planificación. La ley de Goodhart describe bien el efecto: cuando una medida se convierte en un objetivo, deja de ser una buena medida.
- Comparar la velocidad entre equipos. Cada equipo tiene su propia escala de puntos, así que 40 puntos en un equipo y 20 en otro no dicen nada sobre quién entrega más.
- Fijar objetivos de velocidad. Pedir «un 10% más de puntos el próximo trimestre» produce sobre todo estimaciones más grandes, no más valor entregado.
- Usar la velocidad en las evaluaciones individuales. La velocidad es una métrica de equipo; repartirla por persona fomenta la optimización local y desincentiva la programación en pareja y la revisión de código.
- Contar el trabajo a medio hacer. Reconocer historias sin terminar hace que la velocidad parezca estable cuando la entrega no lo es.
- Ignorar la calidad. Una velocidad al alza acompañada de más defectos escapados o despliegues fallidos suele significar que el equipo está tomando atajos.
- Planificar con la velocidad máxima. Comprometerse con el mejor sprint de la historia no deja margen para el trabajo imprevisto y hace que la mayoría de los sprints parezcan fracasos.
- Recalibrar los story points en silencio. Cambiar las historias de referencia sin reiniciar el histórico de velocidad rompe la comparabilidad.
¿Cómo mejorar la velocidad sin manipular los story points?
La velocidad se mejora de forma sostenible eliminando fricciones del sistema de entrega, como las historias demasiado grandes, los tiempos de espera y el retrabajo, en lugar de presionar a las personas para que terminen más puntos. Una mejora real se nota en una velocidad más alta o más estable, con una calidad constante y un tiempo de ciclo más corto.
- Divida las historias en partes más pequeñas. Los elementos que caben en dos o tres días rara vez se arrastran, y eso hace la velocidad más predecible.
- Limite el trabajo en curso. Terminar antes de empezar algo nuevo reduce los cambios de contexto y los elementos a medias al final del sprint.
- Acorte los tiempos de revisión de código y de CI. Una revisión en el mismo día y un pipeline rápido y fiable acortan el camino hasta «terminado».
- Invierta en pruebas automatizadas. Una batería de pruebas sólida reduce las pruebas de regresión manuales y el retrabajo que sigue a los defectos escapados.
- Reduzca la deuda técnica de forma deliberada. Reserve una parte fija de cada sprint para la deuda en las áreas que más ralentizan al equipo.
- Proteja al equipo del trabajo imprevisto. Canalice el soporte y las peticiones urgentes a través de una sola persona en rotación en lugar de interrumpir a todos.
- Haga retrospectivas con datos reales. Revise el trabajo arrastrado, el tiempo bloqueado y el tiempo de ciclo, elija una mejora por sprint y compruebe si funcionó.
¿Cómo cambian la velocidad las herramientas de programación con IA en 2026?
Los asistentes de programación con IA pueden aumentar la cantidad de código que produce un equipo, pero en 2026 hacen que la velocidad sea más difícil de interpretar, porque programar más rápido no significa automáticamente entregar antes software que funcione. Al adoptar herramientas de IA, los equipos deberían vigilar las métricas de calidad y estabilidad junto a la velocidad.
El informe DORA 2025 sobre el desarrollo de software asistido por IA concluyó que alrededor del 90% de los profesionales tecnológicos encuestados usan la IA en el trabajo y que la adopción de la IA tiene ya una relación positiva con el throughput de entrega. La misma investigación halló que la adopción de la IA sigue correlacionada con una mayor inestabilidad de la entrega, es decir, más cambios fallidos y más retrabajo. DORA describe la IA como un amplificador: refuerza los buenos sistemas de ingeniería y deja al descubierto los débiles.
- Recalibre las estimaciones. Si las tareas rutinarias se aceleran con la IA, puede que haya que volver a estimar las historias de referencia; en ese caso, reinicie la base de la velocidad.
- Vigile la carga de revisión. Más código generado suele desplazar el cuello de botella a la revisión de código y a las pruebas, lo que limita la velocidad real.
- Siga la tasa de fallos de cambios. Un aumento de la velocidad con una tasa de fallos de cambios al alza no es una mejora.
¿Qué le dice la velocidad sobre un equipo de desarrollo externalizado?
La velocidad le dice si un equipo externalizado es predecible, no si es productivo ni si compensa lo que cuesta. Una velocidad estable con rangos de entrega honestos es una buena señal; una velocidad que no deja de subir suele indicar inflación.
Cuando trabaje con un equipo externo o con un equipo de desarrollo dedicado, haga cuatro preguntas sencillas: ¿cómo estiman?, ¿qué incluye su Definition of Done?, ¿qué ocurre con el trabajo arrastrado? y ¿cómo prevén una entrega? Después pida ver la velocidad junto al tiempo de ciclo, los defectos escapados y la frecuencia de despliegue. Un proveedor que solo informa de story points, o que promete una velocidad fija antes de conocer su base de código, vende una cifra en lugar de un proceso de entrega.
Preguntas frecuentes
¿Qué es la velocidad en el desarrollo de software?
La velocidad en el desarrollo de software es la cantidad de trabajo que un equipo ágil completa en un sprint, medida en story points o en otra unidad coherente. Solo cuentan los elementos que cumplen la Definition of Done. Los equipos promedian la velocidad de varios sprints para planificar cuánto trabajo asumir y prever cuándo terminará un backlog.
¿Cómo se calcula la velocidad ágil?
Sume los story points de todos los elementos completados en un sprint para obtener la velocidad de ese sprint y, después, promedie los totales de los últimos tres a cinco sprints de igual duración. Por ejemplo, sprints con 30, 34 y 32 puntos completados dan una velocidad media de 32 puntos por sprint. Los elementos sin terminar cuentan como cero.
¿Cuál es una buena velocidad para un equipo Scrum?
No existe una velocidad buena en términos universales, porque cada equipo usa su propia escala de story points. Una buena velocidad es estable y predecible: permite al equipo cumplir sus objetivos de sprint y prever las entregas dentro de un rango acordado. Las grandes oscilaciones de un sprint a otro importan más que la cifra absoluta.
¿Se debe usar la velocidad para comparar equipos?
No. La velocidad no debe usarse para comparar equipos, porque cada uno estima con su propia escala relativa y trabaja con código, riesgos y dependencias distintos. Comparar velocidades entre equipos fomenta la inflación de puntos. Para comparar equipos, utilice métricas de resultados y de entrega como el lead time, la frecuencia de despliegue y la tasa de fallos de cambios.
¿Qué diferencia hay entre la velocidad y un burndown chart?
La velocidad es la cantidad de trabajo completada por sprint, mientras que un burndown chart muestra el trabajo restante de un sprint o de una entrega a lo largo del tiempo. La velocidad sirve para planificar los próximos sprints; el burndown chart sirve para seguir el avance del sprint o de la entrega en curso y detectar pronto que el plan está en riesgo.
¿Exige Scrum que los equipos midan la velocidad?
No. La Scrum Guide no menciona ni la velocidad ni los story points. Solo indica que el equipo tiene en cuenta su rendimiento pasado y su capacidad prevista al seleccionar el trabajo en el Sprint Planning. La velocidad es una práctica complementaria muy extendida, y algunos equipos la sustituyen por el throughput o por previsiones probabilísticas.
¿Por qué baja la velocidad de un equipo?
La velocidad de un equipo suele bajar por una capacidad reducida, como vacaciones o bajas por enfermedad, por cambios en el equipo, por trabajo no planificado como incidencias en producción, por una deuda técnica creciente, por historias grandes que se arrastran al siguiente sprint o por revisiones de código y pruebas lentas. Analice la causa en una retrospectiva antes de reaccionar, porque una caída puntual suele ser una variación normal.