Velocidad de un equipo de desarrollo: cómo medirla de verdad (y por qué la IA no la duplica)

Tu equipo termina sus sprints, los story points suben, el backlog baja. Sin embargo, la puesta en producción se atasca, los bugs se acumulan y el time-to-market no se mueve. El problema no es la velocidad del código, sino lo que estás midiendo.

He visto equipos con 80 puntos por sprint que entregaban una feature utilizable por trimestre. Y he visto otros con 30 puntos sacar un MVP en tres semanas. La diferencia está en las métricas que guían las decisiones, no en el talento de los desarrolladores.

Qué mide la velocidad (y qué no mide)

La velocidad ágil, en el sentido Scrum, corresponde a la suma de los puntos de esfuerzo de los ítems completados al final del sprint. Según Axify, sirve como herramienta de planificación de capacidad: cuánto trabajo puede absorber el equipo en el próximo sprint. Nada más.

La trampa es conocida y, sin embargo, omnipresente: usar la velocidad como KPI de rendimiento. Un estudio de McKinsey de 2023 muestra que las organizaciones que miden la productividad dev únicamente por el volumen de código entregado rinden entre un 20 y un 30 % menos en time-to-market que las que adoptan métricas sistémicas. Cuando un manager pregunta «¿por qué bajó la velocidad este sprint?», está transformando un indicador de capacidad en herramienta de presión.

¿Los story points miden la productividad?

No. Los story points combinan esfuerzo, riesgo, incertidumbre y complejidad. Son subjetivos por diseño: un equipo que va ganando experiencia puede estimar las mismas tareas con menos puntos, sin que su productividad haya bajado. Según Bocasay, la velocidad a veces disminuye con el tiempo precisamente porque el equipo estima mejor.

Cuando la velocidad se convierte en un objetivo, los desarrolladores inflan las estimaciones. Es la ley de Goodhart aplicada al sprint planning: «cuando una métrica se convierte en un objetivo de gestión, deja de ser una buena medida.»

La velocidad Scrum nunca fue diseñada para comparar dos equipos entre sí. Comparar 50 puntos del equipo A con 35 del equipo B es como comparar kilómetros y millas sin conversión.

¿Por qué el throughput es más fiable?

El throughput (flujo) cuenta el número de ítems entregados en producción por unidad de tiempo. No los puntos estimados, no las líneas de código: las funcionalidades realmente desplegadas y validadas. La métrica es objetiva (un ítem está entregado o no lo está) y captura toda la cadena, del commit al despliegue.

Cuando tu throughput se estanca mientras tu velocidad sube, el cuello de botella está aguas abajo: revisión de código, QA, despliegue, validación de negocio. Es exactamente lo que las métricas DORA formalizan.

Las 4 métricas DORA: el estándar que reemplaza la intuición

El programa DORA (DevOps Research and Assessment), impulsado por Google Cloud desde 2018, ha analizado más de 39 000 respuestas de profesionales a lo largo de nueve años. El informe Accelerate State of DevOps identifica cuatro métricas clave que predicen el rendimiento de un equipo de ingeniería.

¿Qué son exactamente las métricas DORA?

Dos ejes, cuatro indicadores.

Eje velocidad:

• Deployment Frequency: cuántas veces el equipo despliega en producción por periodo. Los equipos élite despliegan varias veces al día.
• Lead Time for Changes: el tiempo entre el primer commit y la puesta en producción. Menos de una hora en los mejores equipos.

Eje estabilidad:

• Change Failure Rate: el porcentaje de despliegues que provocan un incidente o un rollback. Por debajo del 5 % en los equipos élite.
• Time to Restore Service: cuánto tiempo se tarda en restablecer el servicio tras un incidente. Menos de una hora.

La investigación DORA muestra un resultado contraintuitivo: velocidad y estabilidad no son un compromiso. Los equipos que despliegan con mayor frecuencia son también los que tienen la tasa de fallo más baja, porque sus despliegues son pequeños, testeados y reversibles.

¿Cómo implementar el seguimiento DORA en un equipo pequeño?

No hace falta una plataforma de engineering intelligence a 50 000 €/año. Un dashboard en Grafana o Datadog conectado a tu pipeline CI/CD es suficiente. La tasa de fallo se deduce de los rollbacks etiquetados. El tiempo de restauración se lee en PagerDuty u Opsgenie.

En las misiones que dirijo, empezamos midiendo el lead time. Es la métrica que revela más rápido los verdaderos cuellos de botella. Un lead time de 12 días en un equipo de 4 desarrolladores rara vez apunta a un problema de velocidad de codificación. Apunta a un proceso de review que se arrastra o una validación de PO que espera al comité del jueves.

SPACE y DXCore: cuando el factor humano entra en la ecuación

DORA mide la máquina. Pero una pipeline perfecta no vale nada si el equipo está en burnout. El framework SPACE, desarrollado por Microsoft Research en 2021, complementa DORA añadiendo cinco dimensiones centradas en la experiencia del desarrollador.

¿En qué complementa SPACE a las métricas DORA?

SPACE cubre cinco ejes: Satisfacción y bienestar (eNPS, burnout), Performance (capacidad de las herramientas para cumplir su función), Actividad (commits, PRs, solo como señal de contexto), Comunicación y colaboración (tiempo de review, coordinación cross-team), Eficiencia y flow (tiempo de trabajo sin interrupciones, coste del context switching).

El punto clave: la actividad nunca se utiliza como métrica aislada. Un desarrollador que hace 40 commits por semana con un tiempo de review medio de 4 días y una puntuación de satisfacción de 3/10 no es productivo. Se está agotando en un sistema que no procesa sus PRs.

Cada métrica de velocidad debe ser contrarrestada por una métrica de calidad. La frecuencia de despliegue sin la tasa de fallo es velocidad ciega. El volumen de commits sin el feedback de satisfacción es explotación. DXCore 4 formaliza esta tensión consolidando las señales en cuatro pilares equilibrados: velocidad, eficiencia, calidad e impacto de negocio.

Aplico esta lógica en cada misión en régie. Cuando dirijo un dev a distancia, el ritual diario de 30 minutos no sirve para verificar que «codifica suficientemente rápido». Sirve para detectar los bloqueos de review, las specs difusas, las interrupciones no planificadas. Son esas fricciones, no la velocidad de tecleo, las que matan la velocidad real.

La IA acelera el código, no la delivery

Este es el momento en que la mayoría de los artículos sobre velocidad pierden el hilo. Te prometen que Copilot, Cursor o Claude Code van a «duplicar la productividad». Los datos de campo cuentan otra historia.

¿La IA realmente aumenta la productividad de los desarrolladores?

El informe DORA 2024 aporta cifras claras: el 75,9 % de los desarrolladores encuestados utilizan IA para el código. De ellos, el 75 % declara ganancias de productividad percibidas. Pero las métricas objetivas muestran lo contrario: el throughput cae un 1,5 % y la estabilidad baja un 7,2 % en los equipos que adoptaron la IA, en comparación con los que no la utilizan.

El estudio METR, publicado a principios de 2025, lo confirma con más contundencia. Sobre 246 issues reales tratadas por 16 desarrolladores open-source experimentados, el uso de Cursor Pro con Claude 3.5 y 3.7 Sonnet produjo una caída de productividad del 19 % respecto al trabajo sin IA. Los desarrolladores esperaban una ganancia del 24 %. La brecha entre percepción y realidad alcanza los 43 puntos.

«La IA genera código más rápido. Pero el código es solo un tercio de la delivery. Los otros dos tercios (review, test, despliegue) absorben el excedente y ralentizan.»

Vincent Roye, junio 2026

¿Por qué la IA ralentiza la delivery cuando no está bien enmarcada?

El problema no es la IA en sí, es la sobrecarga aguas abajo. Cuando un desarrollador genera tres veces más código al día, la cola de review se triplica. QA recibe PRs más voluminosas. El lead time se dispara aunque la «velocidad» percibida se haya disparado también.

En el informe DORA/Uplatz, el análisis es nítido: en 2024, la generación de código asistida por IA representa el 41 % del output total. Sin embargo, la velocidad de delivery efectiva retrocedió un 19 %. La razón cabe en una frase: los cuellos de botella migraron del desarrollo a la validación.

Mi experiencia lo confirma. Un desarrollador aumentado con IA solo gana en velocidad real si se cumplen tres condiciones: specs desglosadas en bloques cortos con criterios de aceptación precisos, una review sistemática del código generado por un senior que conoce la arquitectura, y una pipeline CI/CD que absorba el flujo sin cola de espera.

Sin ese encuadre, la IA acelera la acumulación de deuda técnica. Según el análisis Uplatz, cerca de la mitad del código generado por IA termina en los repositorios sin haber sido verificado funcionalmente.

Cómo mejorar la velocidad sin hacer trampas

Mejorar la velocidad real (medida en DORA, no en story points) pasa por tres palancas.

¿Hay que invertir en la pipeline antes de invertir en IA?

Sí. Cada paso manual entre el commit y producción es un impuesto sobre el lead time. Infrastructure as Code, tests automatizados, despliegue continuo: estos fundamentos dividen el lead time por un factor de 5 a 10 antes siquiera de hablar de IA.

La segunda palanca toca el tamaño de los cambios. PRs más pequeñas se revisan más rápido, se testean más rápido y rompen menos a menudo. Cuando incorporo un dev senior en régie, la consigna es siempre la misma: ninguna PR de más de 300 líneas. Por encima de eso, el tiempo de review crece exponencialmente y la tasa de fallo se dispara.

La tercera palanca es el encuadre de la IA. La verdadera ventaja no es usar IA, sino construir un sistema de producción de software industrializado a su alrededor: archivos de contexto de proyecto (CLAUDE.md, ARCHITECTURE.md, CONVENTIONS.md), specs desglosadas en tareas testeables, review obligatoria antes del merge. Con ese encuadre, un senior aumentado con IA y un mínimo de 8 años de experiencia entrega un throughput real superior al de dos juniors sin encuadrar.

¿Cómo evitar la ley de Goodhart en las métricas dev?

Construyendo una arquitectura de medición basada en la tensión entre métricas concurrentes. La frecuencia de despliegue se verifica con la tasa de fallo. El throughput se verifica con el NPS del desarrollador. El volumen de código se verifica con el porcentaje de rework (código modificado en los 14 días posteriores al merge).

El informe State of DevOps de Google Cloud recomienda medir los sistemas, no a los individuos. Cuando las métricas detectan una desaceleración, la pregunta no es «¿quién trabaja demasiado lento?» sino «¿qué proceso está generando fricción?».