Guardado en Notion → abrir draft

Acá va el artículo completo:

La Velocity Está Rota: Por Qué Tu Métrica de Agile Más Importante Ya No Funciona en la Era de la IA

La velocity nunca fue una métrica perfecta. Pero era útil — hasta que las herramientas de coding con IA dejaron completamente falso el supuesto sobre el que descansa.

Durante dos décadas, la velocity le dio a los equipos Agile algo valioso: un lenguaje compartido para hablar de capacidad.

No un lenguaje perfecto. Los practicantes siempre supieron que los story points son relativos, que la velocity varía por equipo, que compararla entre equipos es un error. La comunidad Agile construyó currículums enteros sobre los usos correctos e incorrectos de la métrica.

Pero debajo de toda esa matización, la velocity descansaba sobre un supuesto que nadie cuestionaba — porque era tan obviamente verdadero que no necesitaba enunciarse.

El supuesto: los story points miden esfuerzo humano.

Una historia de cinco puntos requería aproximadamente cinco puntos de pensamiento, decisión, escritura y construcción humanos. La velocity sostenible de un equipo reflejaba la cantidad de atención humana enfocada que podían mantener durante un sprint de dos semanas. Cuando la velocity subía, significaba que el equipo se estaba mejorando, acelerando, o ambas cosas.

Ese supuesto ahora es falso.

No debilitado. No en necesidad de recalibración. Falso.

Y las organizaciones que no se dieron cuenta están tomando decisiones de capacidad, compromisos de roadmap, evaluaciones de performance y planes de contratación basados en un número que dejó de significar lo que creen que significa en el momento en que agregaron herramientas de coding con IA al equipo.

Qué Estaba Midiendo Realmente la Velocity

Para entender por qué se rompió la velocity, ayuda entender qué estaba midiendo en primer lugar — y por qué eso funcionaba.

Los story points nunca fueron pensados para medir tiempo. Fueron pensados para medir complejidad relativa, usando el desempeño pasado del equipo como referencia. La intuición detrás de la estimación Agile es que los humanos son pésimos prediciendo duración absoluta pero razonablemente consistentes juzgando tamaño relativo.

“¿Esto es más grande o más chico que el feature de login que construimos el sprint pasado?” produce respuestas más confiables que “¿cuántas horas va a llevar esto?”

La velocity emergió de esto como una herramienta de planning. Si un equipo consistentemente cierra 40 puntos por sprint, podés razonablemente planificar 40 puntos para el siguiente. El número es específico del equipo, específico del sprint, y solo útil en contexto — pero dentro de esas restricciones, funciona.

La razón por la que funciona es que el output humano es relativamente estable. Un developer que escribe 200 líneas de código reflexivo y listo para producción en un día está trabajando con aproximadamente la misma intensidad cognitiva este sprint o el siguiente.

Las herramientas de coding con IA introdujeron algo más desestabilizador: un aumento dramático y asimétrico en la velocidad de generación sin ningún cambio correspondiente en el juicio humano requerido para evaluar esa generación.

El Supuesto Roto en la Práctica

Un equipo de producto está planeando un sprint. Basándose en la velocity histórica, planifican 45 story points.

Hace seis meses, esos 45 puntos habrían tomado aproximadamente diez a doce tickets, cada uno requiriendo pensamiento humano significativo en cada etapa: diseño, implementación, testing, revisión.

Hoy, con herramientas de coding con IA en el workflow, la fase de generación de esos tickets está dramáticamente comprimida. Un ticket que antes llevaba un día ahora lleva dos horas. El scaffold se genera, los edge cases se sugieren, los casos de prueba se delinean. El sprint cierra 45 puntos — en tiempo, en presupuesto, todo verde en el tablero.

Lo que el gráfico de velocity no muestra:

El senior developer pasó el sprint evaluando, corrigiendo y aprobando código generado por IA con aproximadamente tres veces su carga de revisión anterior. Los criterios de aceptación del product owner fueron traducidos por IA a implementación tan rápidamente que las ambigüedades que antes emergían durante el desarrollo nunca emergieron — están sentadas en producción ahora, esperando ser descubiertas. Dos tickets se cerraron con código que pasa todos los tests pero contiene supuestos arquitectónicos que no se sostienen para los edge cases que van a aparecer en tres meses.

Velocity: 45 puntos. Igual que el sprint pasado. Dashboard: verde.

Las Tres Decisiones de Planning que la Velocity Ya No Puede Sustentar

Capacity Planning

Cuando un equipo Scrum planifica un sprint, la pregunta fundamental es: ¿a cuánto podemos comprometernos? La velocity responde diciendo: aproximadamente lo que hicieron antes, ajustado por cambios en el equipo e interrupciones conocidas.

En un equipo asistido por IA, este cálculo está roto porque la relación entre story points y carga cognitiva humana se volvió no lineal e impredecible.

Un sprint donde el equipo genera el doble de código de lo habitual no es un sprint donde el equipo ejerció el doble de juicio. Puede ser un sprint donde un senior developer tomó cuatro veces más decisiones de revisión, acumuló fatiga de decisión significativa para el miércoles, y aprobó varias cosas el jueves a la tarde que habría atrapado el lunes a la mañana.

La restricción de capacidad en un equipo asistido por IA no son las horas de generación. Son las horas de juicio. Y la velocity no mide ninguna de las dos.

Evaluación de Performance

Esta tiene consecuencias organizacionales serias.

Cuando los engineering managers, CTOs y product leaders evalúan el performance del equipo, la velocity casi siempre está en el cuadro. Un equipo que consistentemente cierra 50 puntos está performando mejor que uno que cierra 35, todo lo demás igual.

En un contexto asistido por IA, un equipo cerrando 50 puntos puede estar performando mejor. O puede ser un equipo donde un senior developer agotado está aprobando todo rápidamente para mantener el sprint board verde, acumulando deuda técnica y agotamiento personal simultáneamente.

Amazon descubrió esto en marzo de 2026, cuando un outage de seis horas en su sitio principal de ecommerce fue rastreado hasta deployments de código asistido por IA aprobados sin la revisión adecuada. Sus métricas de velocity habían mostrado performance sólida. Por toda medida Agile tradicional, el equipo estaba en su mejor momento. Hasta que no lo estaba.

Su solución — exigir sign-off de senior engineers para todos los deployments asistidos por IA — es esencialmente un reconocimiento de que la velocity estaba midiendo la cosa equivocada. La métrica mostraba que la generación estaba pasando rápido. No mostraba que el juicio se estaba degradando.

Compromisos de Roadmap

“Basándonos en nuestra velocity actual, podemos entregar el nuevo onboarding flow para Q2.”

Este tipo de declaración se hace en cada organización de producto, todas las semanas. Depende completamente de la creencia de que la velocity pasada predice la capacidad futura.

En un equipo asistido por IA, esta predicción es menos confiable de lo que parece — no porque el equipo vaya a desacelerarse, sino porque los costos ocultos de la velocity asistida por IA no se distribuyen uniformemente en el tiempo. El código generado rápidamente en Q1 genera carga de mantenimiento en Q2. La deuda técnica acumulada invisiblemente durante sprints de alta velocity aparece como trabajo no planificado durante los sprints en los que te comprometiste a entregar.

El número de velocity era real. La capacidad que implicaba no lo era.

El Principio Agile que la Velocity Debía Proteger

Hay una ironía acá que vale la pena nombrar.

Uno de los compromisos centrales del desarrollo Agile es el ritmo sostenible. El duodécimo principio del Manifiesto Agile: “Los procesos Agile promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.”

La velocity fue en parte una herramienta para hacer cumplir este principio. “No podemos comprometernos a 60 puntos — nuestra velocity es 40” es una declaración de capacidad sostenible, no de pereza.

Las herramientas de coding con IA crearon una situación donde la velocity parece aumentar sosteniblemente — el gráfico sube y se mantiene arriba — mientras la carga cognitiva humana real aumenta hacia la insostenibilidad.

La métrica que debía proteger el ritmo sostenible ahora está oscureciendo activamente la violación de él.

Qué Necesitan Medir Realmente los Equipos Agile

Quiero ser directo sobre algo: no tengo un reemplazo limpio para la velocity. Tampoco lo tiene la comunidad Agile. Las herramientas, los frameworks y los modelos mentales para medir la salud del equipo en un contexto asistido por IA todavía se están construyendo.

Lo que puedo ofrecer es un conjunto de preguntas más honestas sobre lo que importa — y algunos indicadores adelantados que capturan lo que la velocity se pierde.

Calidad del review, no completitud del review. La diferencia entre un sprint donde un senior developer revisó veinte pull requests y dio feedback sustantivo en ocho versus uno donde revisó veinte y no hizo pushback en ninguno es enorme. Trackeá el ratio de feedback sustantivo sobre aprobaciones silenciosas. Mirá qué le pasa a ese ratio los viernes a la tarde.

Tracking del origen de defectos. Cuando aparecen bugs en producción, rastreálos. ¿Fue código generado por IA aprobado rápidamente? ¿Fue un módulo donde el review fue superficial? Esto no es sobre culpa — es sobre calibración.

Ratio de trabajo no planificado. La señal más clara de deuda técnica acumulada es el porcentaje de capacidad del sprint consumido por trabajo no planificado. Un equipo cuya velocity está subiendo pero cuyo trabajo no planificado también está subiendo está acumulando deuda más rápido de lo que está entregando valor.

Muestreo de comprensión. Una vez al mes, elegí cinco tickets que cerraron en el último sprint y pedile al developer que te explique la implementación en una revisión técnica de treinta minutos. Si las respuestas son delgadas y dudosas, tenés “confidence debt”: código que funciona hoy pero que no puede mantenerse mañana porque nadie en el equipo lo entiende completamente.

Check-ins de ritmo sostenible. Preguntale directamente a tu equipo, semanalmente: del uno al diez, ¿cómo calificarías la calidad de tus decisiones hoy comparado con el lunes a la mañana? La mayoría de los developers experimentados ya rastrean esto intuitivamente. La pregunta es si tu organización crea espacio para que esa respuesta emerja antes de que se convierta en un problema de retención.

La Implicación Incómoda para la Práctica Agile

La velocity no es la única métrica Agile que la IA perturba. Es solo la más prominente.

El sprint planning asume que el desempeño pasado predice la capacidad futura. La IA cambia la relación entre esfuerzo y output de maneras que hacen esto poco confiable.

La Definition of Done asume que un ticket completado representa una unidad de trabajo entendido y listo para producción. El código generado por IA puede satisfacer cada criterio mientras sigue siendo código que nadie en el equipo podría reconstruir de memoria.

Las retrospectivas deberían sacar a la superficie lo que desaceleró al equipo. Pero la AI Fatigue no se siente como desaceleración — se siente como aceleración. No hacés una retrospectiva sobre ir demasiado rápido.

Nada de esto significa que Agile está roto. Los valores — colaboración, software funcionando, responder al cambio, ritmo sostenible — son tan relevantes como siempre. Las prácticas necesitan evolucionar para dar cuenta de un mundo donde el cuello de botella ya no es la velocidad de ejecución humana.

Un Pensamiento Final

Cada gran cambio en cómo se construye software ha requerido eventualmente un cambio en cómo los equipos miden su salud.

Waterfall dio paso a Agile cuando la industria reconoció que la planificación en grandes lotes no coincidía con la realidad. La velocity y los story points emergieron como mejores herramientas para un proceso más iterativo y centrado en el humano.

El desarrollo asistido por IA es otro cambio de magnitud comparable. Las herramientas son diferentes. Los cuellos de botella son diferentes. Los modos de falla son diferentes.

La velocity nos sirvió bien. Durante veinte años, ayudó a los equipos a planificar honestamente, resistir el sobre-compromiso y construir a un ritmo sostenible. Era una buena solución al problema que fue diseñada para resolver.

Ese problema cambió.

Los equipos que reconozcan esto temprano — y empiecen a construir prácticas de medición que capturen la calidad del juicio, la sostenibilidad humana y la coherencia arquitectónica — van a tener una ventaja significativa sobre los equipos que sigan celebrando dashboards verdes hasta que algo se rompa.

El dashboard va a estar verde. La pregunta es qué no te está mostrando.