Métricas tóxicas: story points, commits y otras formas creativas de autoengañarse

Publicado el 13 de abril de 2026  •  20 minutos  • 4146 palabras

Hay muchas formas de destrozar un equipo de desarrollo.

Puedes forzarles a usar un framework que nadie pidió, obligarles a estimar hasta la última coma en una reunión de cuatro horas, o —mi favorita— ponerles métricas equivocadas y llamarlo “gestión por datos”. Es elegante, suena profesional en una presentación, y el daño tarda lo justo en notarse como para que el responsable ya haya sido ascendido.

Cuando conviertes story points, commits o líneas de código en objetivo, no mides productividad: diseñas un juego en el que todo el mundo va a aprender a hacer trampas.

Y lo peor es que no puedes culparles, porque es exactamente lo racional cuando las reglas están rotas.

Cuando el KPI es “parecer ocupado”, no crear valor

En 1975, Charles Goodhart —un economista británico que asesoraba al Banco de Inglaterra— formuló una idea que debería estar tatuada en la frente de todo director de ingeniería: “Cuando una medida se convierte en objetivo, deja de ser una buena medida.”

Lo dijo pensando en política monetaria, pero, como todas las buenas verdades, aplica universalmente.

En ingeniería de software llevamos décadas demostrando que Goodhart se quedó corto: no solo dejamos de medir bien, sino que nos las ingeniamos para que la métrica diga exactamente lo que queremos oír.

Story points como medidor de productividad

Imagina a un jefe que un lunes anuncia, muy convencido: “a partir de ahora vamos a medir la productividad individual en story points, así sabremos quién aporta más”. Lo dice con la misma seguridad con la que alguien propone medir la calidad de un restaurante contando el número de platos que salen de la cocina

En la primera retrospectiva, alguien ya ha aprendido el truco: “si esta tarea que antes era un 3 ahora la marcamos como 5, de repente somos más productivos sin escribir una sola línea más”. Milagro. Sagrada inflación.

Los story points son una estimación relativa de complejidad, no una unidad de valor entregado. Un punto “3” en un equipo no significa lo mismo que en otro, ni siquiera en el mismo equipo seis meses después. Mike Cohn , que popularizó su uso desde Mountain Goat Software , lleva años explicando que los story points estiman esfuerzo relativo, no complejidad absoluta, y mucho menos productividad individual.

Pero da igual cuántas veces lo repita: en cuanto alguien con acceso a un Excel decide que “velocity = rendimiento”, la planificación se convierte en un teatro de números donde el que más infla gana, el que estima con honestidad parece lento, y la calidad del producto se va de vacaciones sin fecha de vuelta. Los equipos empiezan a trocear tareas en subtareas absurdas para sumar puntos, inflan estimaciones para que la gráfica no caiga, y evitan el trabajo difícil o incierto porque “igual nos tumba la media del sprint”. Nadie quiere ser el responsable de que la curva baje, aunque la curva no signifique absolutamente nada.

Commits por desarrollador

La película de los commits es todavía más divertida. Contar commits te dice cuántas veces alguien ha pulsado git commit, no si ha hecho algo útil. Es como medir la productividad de un escritor contando las veces que pulsa “Guardar”. Trivial de optimizar : divides un cambio coherente en commits ridículos, guardas cada corrección de typo como un commit separado, cambias espacios por tabuladores y —voilà— tu curva de “productividad” se dispara. Tu código es un desastre, pero el dashboard brilla.

Hay empresas que han llegado a implantar paneles públicos con commits por persona “para fomentar la transparencia”. Lo que fomentan en realidad es lo contrario: la gente deja de hacer refactors profundos (porque tocar mucho código en pocos commits queda “flojo”), los sénior reducen el tiempo que dedican a revisar código ajeno (porque revisar no te suma en la tabla de posiciones), y aparecen commits del tipo rename variable, fix typo, add whitespace, todos cuidadosamente separados para que la gráfica suba.

En un hilo de Reddit que merece la pena leer, un desarrollador contaba cómo acabó haciendo commits de cambios triviales y de formato solo para mejorar sus métricas, generando un infierno de ruido para quien tuvo que revisar y mantener ese código después. En el dashboard quedaba precioso; en la base de código, como si hubiera pasado un huracán con TOC.

Líneas de código (LOC)

Y luego están las líneas de código, la cucaracha de las métricas: puedes tirarle décadas de literatura encima y ahí sigue, apareciendo en powerpoints de “productividad” con la misma resistencia que las cucarachas sobreviven a todo lo demás.

Más líneas de código no significan más valor. En la inmensa mayoría de los casos, buen diseño implica menos código: más claro, más mantenible, más fácil de razonar. Martin Fowler —uno de los firmantes del Manifiesto Ágil y autor de referencia en refactoring y arquitectura de software— lleva años escribiendo sobre cómo medir por LOC incentiva justo lo contrario de lo deseable: verbosidad, complejidad artificiosa y cero refactors. Si premias las líneas añadidas, nadie quiere borrar código muerto (“borrar resta puntos”), las soluciones simples se rechazan porque “saben a poco”, y las implementaciones se engordan con capas de abstracción que solo existen para que el número suba. Es como premiar a un cirujano por el tiempo que pasa en quirófano en lugar de por la salud del paciente: técnicamente medible, prácticamente suicida.

El resultado está documentado hasta la saciedad: empresas que intentan medir productividad con puntos, commits o LOC acaban con números preciosos… y software mediocre, deuda técnica creciente y equipos cínicos que han aprendido que su trabajo no es crear buen producto, sino sobrevivir al siguiente QBR con las métricas presentables.

El teatro de las líneas de código: el caso Twitter/Musk

Si necesitas un ejemplo de métrica absurda elevada a categoría de arte marcial, no busques más allá de octubre de 2022. Cuando Elon Musk —CEO de Tesla, SpaceX y en ese momento recién estrenado dueño de Twitter por la módica cifra de 44.000 millones de dólares— tomó el control de la red social, una de las primeras cosas que hizo fue pedir a los ingenieros que imprimieran su código reciente para revisarlo. Sí, imprimieran. En 2022. Como si el control de versiones fuese una moda pasajera.

Según reportaron Le Monde , The Guardian y Business Insider (que inmortalizó la imagen de Musk saliendo de una “revisión de código” a la 1:30 AM, como si eso fuese algo de lo que presumir), la cantidad de líneas de código producidas se consideró una señal importante para decidir quién se quedaba y quién no en los despidos masivos que siguieron. Uno de los managers despedidos lo describió como “gente tomando decisiones sobre personas que no conocen, basadas en el número de líneas de código que han escrito; completamente absurdo”.

La comunidad técnica reaccionó, como era de esperar, con una mezcla de horror y cachondeo. Reducir el trabajo de un ingeniero a “cuántas líneas has escrito” ignora todo lo que hace valiosa a una persona técnica: refactors que reducen complejidad, eliminación de código muerto, trabajo de diseño que evita que se escriba código innecesario, revisiones de PRs que salvan al equipo de errores caros, o la resolución de problemas complejos que precisamente consiste en no añadir código sino en entender por qué no funciona el que ya hay. Bloomberg analizó cómo esos despidos indiscriminados arrasaron con conocimiento institucional que tardó años en construirse. Fortune documentó las oleadas de renuncias que siguieron cuando los supervivientes entendieron las reglas del nuevo juego.

Si incentivas líneas de código, obtienes líneas de código. No buen software. Es un caso de libro de cómo una métrica grotesca puede llevar a decisiones igualmente grotescas, con impacto directo en la cultura, la calidad del sistema y la confianza en la dirección. Aunque, siendo justos, también fue un caso de libro de muchas otras cosas.

Aunque confiar en las ideas de Elon Musk, es como confiar en un mono con una ballesta, pero esa es otra historia que será contada en otra ocasión.

El catálogo de métricas tóxicas (y cómo se tuercen)

No todas las métricas tóxicas llevan el logo de una empresa famosa ni necesitan un multimillonario excéntrico para causar daño. Los patrones se repiten una y otra vez, en startups de garaje y en corporaciones del Fortune 500, con la misma previsibilidad con la que el café de la oficina siempre está frío cuando lo necesitas caliente.

Story points completados por sprint / por persona

Cuando alguien decide usar story points para medir rendimiento individual, tiene todos los ingredientes para una tragicomedia en tres actos. El problema de base es sencillo: los story points son estimaciones subjetivas y relativas, no unidades de medida. Usarlos como KPI es como medir la inteligencia de alguien por cuántas veces dice “sinergias” en una reunión.

Lo que suele pasar en la práctica es una espiral de locura bastante documentada. Los puntos se hinchan porque nadie quiere que su gráfica baje. El trabajo difícil o incierto se evita como la peste, porque amenaza la “velocity”. Las tareas importantes se trocean en subtareas absurdas —cosas que podrían ser un commit se convierten en cinco tickets— solo para que “el sistema” te premie. En un hilo revelador en r/agile , equipos técnicamente brillantes pero honestos con sus estimaciones acababan vistos como “peores” que equipos que hinchaban sus puntos y generaban features mediocres a toda velocidad. La diferencia no estaba en el valor entregado, sino en quién sabía jugar mejor al juego de los números.

Número de commits

Como métrica individual, el número de commits tiene la misma profundidad analítica que contar cuántas veces alguien abre el frigorífico para evaluar si come bien. No mide tamaño, ni valor, ni calidad del cambio. Pero eso no impide que aparezca regularmente en cuadros de mando etiquetados como “ingenieros de alta performance”.

Los efectos son tan predecibles que casi aburre enumerarlos: commits minúsculos y ruidosos que saturan el historial y hacen imposible seguir el contexto de un cambio real, menos trabajo profundo porque el trabajo profundo suele materializarse en pocos commits sustanciosos (que quedan “flojos” en la estadística), y seniors que dejan de revisar código ajeno porque dedicar dos horas a evitar que un junior meta un bug crítico no suma absolutamente nada en la tabla de posiciones.

Y lo más triste es ver cómo los sénior dejan de revisar código ajeno, porque dedicar una hora a una revisión a fondo ayuda enormemente al equipo… pero no suma ni un commit a tu contador.

El conteo de PRs tiene la misma trampa que los commits, pero con más ceremonia alrededor, como si ponerle corbata a un error lo hiciese más respetable. No todas las PRs tienen el mismo peso: una puede ser una corrección de una palabra en un README y otra puede ser una migración de arquitectura que lleva tres semanas de diseño, negociación y dolor.

Cuando conviertes las PRs cerradas en objetivo, lo que obtienes no es más productividad, sino más burocracia disfrazada de output. Las PRs triviales proliferan, el trabajo se fragmenta hasta el absurdo (metiendo más overhead de revisión que valor real), y la gente abre PRs de “preparación” que perfectamente podrían ir juntas, pero separadas suman más puntos. Es la versión corporativa de trocear un bocadillo en rodajas para decir que has comido cinco platos.

Líneas de código añadidas

Ya hemos visto el caso Musk, pero el problema es mucho más general que un multimillonario con tendencia al espectáculo. Cualquier sistema que premia LOC añadidas genera un incentivo perverso: resistirse a borrar código muerto se convierte en conducta racional, los refactors desaparecen porque restas líneas, y las soluciones se engordan artificialmente porque el sistema te paga por ello. Es como premiar a un fontanero por el número de tuberías que instala: tarde o temprano tu casa tiene más tuberías que paredes.

Velocity como medidor de rendimiento del equipo

La velocity nació con una función concreta y razonable: ayudar a un equipo a predecir cuánta capacidad tiene en un contexto determinado. Es una herramienta interna de planificación, como el velocímetro de un coche: te dice a qué velocidad vas, no si estás yendo al sitio correcto. Pero alguien siempre decide que quedaría genial en un informe al board, y ahí empieza el desastre.

Cuando la velocity se convierte en KPI de rendimiento, las estimaciones se manipulan, se presiona para “no bajar la velocidad” aunque el contexto haya cambiado radicalmente (nuevo equipo, nueva tecnología, deuda técnica acumulada), y el foco de todo el mundo pasa de “resolver problemas de negocio” a “cumplir la cuota de puntos”. Es como juzgar a un hospital por el número de pacientes que da de alta al día: técnicamente medible, potencialmente criminal.

Qué métricas sí tienen algo de sentido (y cómo se ven en la vida real)

La alternativa no es “no medir nada” —eso sería como tirar el termómetro porque no te gusta la fiebre—. La alternativa es cambiar qué mides y, sobre todo, para qué lo usas. En los últimos años hay bastante consenso alrededor de algunos marcos que, sin ser perfectos, al menos no incentivan activamente el sabotaje.

Métricas DORA: salud de la entrega, no número de teclas

El equipo DORA (DevOps Research and Assessment) —fundado por Nicole Forsgren , Jez Humble y Gene Kim — pasó años investigando qué diferencia a los equipos de ingeniería de alto rendimiento de los que solo lo parecen. El resultado fue el informe State of DevOps (que publican anualmente) y el libro Accelerate (2018), que se convirtió en referencia para medio sector. Tras ser adquiridos por Google, sus métricas se han consolidado como el estándar de facto para medir la salud de entrega de software.

Las cuatro métricas clásicas de DORA no miden cuánto código escribe nadie, sino cómo de sano es el proceso de llevar cambios a producción. La frecuencia de despliegue te dice con qué cadencia eres capaz de entregar valor real (no tickets cerrados, sino software funcionando en manos de usuarios). El lead time for changes mide cuánto tarda un cambio desde que se commitea hasta que está en producción, revelando la fricción acumulada en tu pipeline. La tasa de fallos en cambios te cuenta qué porcentaje de despliegues rompe algo, y el MTTR (tiempo medio de recuperación) cuánto tardas en volver a la normalidad cuando algo explota.

En organizaciones de alto rendimiento ves equipos que despliegan varias veces al día, con pocos fallos, y que son capaces de revertir o arreglar rápido cuando se rompe algo. Esto no te dice “quién trabaja más”, sino “lo sano que es tu sistema de entrega”, que es justo lo que deberías querer saber si te importa el producto y no la pose. Un equipo de una plataforma SaaS que pasa de despliegues quincenales con fines de semana de infierno a despliegues diarios pequeños y controlados no necesariamente cambia el número de commits por persona, pero la experiencia del usuario y la estabilidad del sistema mejoran de forma tangible.

Métricas de flujo y calidad

DORA está bien para el delivery, pero se queda corta si quieres entender cómo se mueve el trabajo dentro del equipo y qué calidad tiene lo que sale. De ahí que muchos equipos la complementen con métricas de flujo y calidad.

El tiempo de ciclo (desde que alguien empieza una tarea hasta que está en producción) revela cuellos de botella que no ves en DORA: esperas en revisión, bloqueos por dependencias, procesos de aprobación kafkianos. El porcentaje de rework —cuánto trabajo es rehacer o parchear cosas que ya se “habían terminado”— es un indicador brutal de calidad real: si un tercio de tu esfuerzo es corregir lo que ya entregaste, tu “velocity” miente. El ratio de bugs post-release te dice cuántos defectos descubren los usuarios que no cazó tu pipeline, y la profundidad de revisión te indica si tus code reviews son una formalidad de “looks good to me” o realmente aportan. Como describe el modelo SPACE (propuesto por investigadoras de Microsoft y GitHub), la productividad tiene dimensiones de satisfacción, rendimiento, actividad, comunicación y eficiencia que no captura ningún número individual.

En equipos sanos ves cómo el tiempo de ciclo baja sin necesidad de “apretar” a nadie: simplemente eliminando cuellos de botella, aclarando prioridades y mejorando el pipeline de CI/CD. El número de tickets cerrados puede incluso bajar, pero los que se cierran de verdad importan.

Métricas de resultado e impacto

Y luego está lo que de verdad te debería quitar el sueño: el efecto de tu trabajo en usuarios y negocio. Porque al final, un equipo no existe para producir commits, ni story points, ni gráficas bonitas. Existe para resolver problemas de gente real.

Las preguntas que sí tienen sentido son del tipo: ¿ha mejorado la conversión después de esa feature? ¿Ha bajado el tiempo de respuesta de la API crítica? ¿Se han reducido las incidencias de soporte relacionadas con ese flujo? ¿Se cumplen los SLOs de disponibilidad y rendimiento del servicio? Google publicó en abierto su SRE Book , que detalla cómo usar SLOs como herramienta de decisión real, no como adorno en un dashboard.

Los mejores equipos que se han estudiado —tanto en los informes DORA como en investigaciones independientes de Microsoft Research — miden outcomes, no solo output: menos “hemos cerrado 40 tickets” y más “hemos reducido un 20% los errores en checkout”. Puede que eso implique semanas de trabajo sin un “gran número” que enseñarle al board, pero el impacto es tangible, medible y —detalle importante— real.

Cómo no convertir las métricas buenas en las siguientes métricas tóxicas

Aquí viene el giro argumental que pocos esperan: incluso las métricas sensatas se pueden corromper. La ley de Goodhart no tiene excepciones. En cuanto conviertes DORA, tiempo de ciclo o cualquier otra métrica en arma de control individual, has creado el siguiente monstruo. La diferencia entre una métrica útil y una tóxica no está solo en qué mides, sino —sobre todo— en cómo lo usas.

Los equipos razonablemente sanos que he visto (y que documentan los informes DORA año tras año) comparten algunas prácticas. Usan métricas a nivel de equipo o sistema, nunca para rankear personas. En cuanto haces un ranking individual con DORA o similares, has perdido el norte exactamente igual que con los story points: solo has cambiado el juego, no las reglas. Combinan datos cuantitativos con contexto cualitativo: encuestas de experiencia del desarrollador , feedback del equipo, análisis de causas raíz. Los números te dicen qué está pasando, pero casi nunca te dicen por qué, y actuar sin el por qué es como medicar sin diagnóstico.

Revisan periódicamente si las métricas que usan están generando comportamientos raros —más rework de lo normal, parches rápidos en lugar de soluciones reales, menos tiempo dedicado a diseño o mentoring— y aceptan sin drama que hay trabajo enormemente valioso que no encaja fácil en un número. Mentoring, diseño de arquitectura, apagar incendios complejos a las tres de la mañana, conocimiento de dominio que solo dos personas tienen: todo eso hay que reconocerlo explícitamente, o acabas penalizando exactamente a la gente que mantiene el sistema en pie.

Un caso que circuló en r/agile lo ilustra mejor que ninguna teoría: un ingeniero sénior cerca de la jubilación, con muy pocos tickets y story points a su nombre, dedicó más de un año a mentorar y transferir conocimiento a la siguiente generación de ingenieros. En cualquier panel de productividad superficial aparecería como “el que menos rinde”. En la práctica, era quien aseguraba que el sistema no se viniese abajo el día que se fuera. Y ese día siempre llega.

Deja de contar teclas y empieza a medir decisiones

Si tus métricas empujan a la gente a escribir más líneas, más commits y más puntos, estás optimizando para parecer ocupado, no para crear buen software.

Story points, commits y LOC pueden servir como inputs contextuales —señales débiles que te ayudan a hacer preguntas—, pero en cuanto los conviertes en objetivo se convierten en armas de destrucción masiva de moral y calidad. Es la diferencia entre usar un termómetro para saber si tienes fiebre y premiar a quien tenga la temperatura más alta.

Si quieres algo que no sea puro teatro, apóyate en métricas como DORA, flujo, calidad y outcomes reales para el usuario, y úsalas para tener conversaciones de equipo sinceras, no para montar rankings de gladiadores.

Todo lo demás es básicamente pagar a gente muy cara para que te gane al juego que tú mismo has diseñado, y luego poner cara de sorpresa cuando el producto no mejora.

Glosario rápido

Por si alguno de estos acrónimos te suena a nombre de protocolo de Star Trek.

• Story points: unidad de estimación relativa que los equipos ágiles usan para valorar el esfuerzo de una tarea. No miden tiempo real, ni productividad, ni valor de negocio. Solo deberían servir para planificar dentro de un equipo concreto.
• Velocity: cantidad de story points que un equipo completa por sprint. Pensada para predecir capacidad interna del equipo, no para comparar equipos ni evaluar rendimiento individual.
• LOC (Lines of Code): líneas de código. Métrica que cuenta cuántas líneas tiene o produce un proyecto o persona. Más líneas no implica más valor; a menudo implica lo contrario.
• KPI (Key Performance Indicator): indicador clave de rendimiento. Cualquier métrica que se usa para evaluar si algo va bien o no. El problema empieza cuando el indicador se convierte en el objetivo.
• QBR (Quarterly Business Review): revisión trimestral de negocio. Reunión donde se presentan resultados a dirección, normalmente con gráficas que alguien intentará usar para justificar decisiones que ya ha tomado.
• DORA: conjunto de cuatro métricas de entrega de software (deployment frequency, lead time, change failure rate, MTTR) definidas por el equipo DORA de Google y popularizadas por el libro Accelerate de Nicole Forsgren, Jez Humble y Gene Kim.
• MTTR (Mean Time to Recovery): tiempo medio de recuperación. Cuánto tarda un equipo en restaurar el servicio tras un fallo en producción.
• SLO (Service Level Objective): objetivo de nivel de servicio. Umbral interno que define cuánta disponibilidad, latencia o fiabilidad debe cumplir un servicio (ej., “99.9% de uptime”). Google detalla su uso en el SRE Book .
• CI/CD (Continuous Integration / Continuous Delivery): prácticas de integración y entrega continua. Automatizar la compilación, pruebas y despliegue del código para llegar a producción con menos riesgo y más frecuencia.
• SPACE: framework de productividad de desarrolladores propuesto por investigadoras de Microsoft y GitHub , que mide satisfacción, rendimiento, actividad, comunicación y eficiencia.
• Rework: retrabajo. Esfuerzo dedicado a rehacer, corregir o parchear algo que ya se había dado por terminado.
• Ley de Goodhart: formulada por el economista británico Charles Goodhart en 1975: “cuando una medida se convierte en objetivo, deja de ser una buena medida”. Principio que explica por qué las métricas de productividad acaban siendo manipuladas en cuanto tienen consecuencias.

Fuentes y referencias

Todo lo que necesitas para montar el argumento de “dejad de contar commits” con algo más que intuición.

• Story Points Estimate Effort, Not Just Complexity — Mike Cohn / Mountain Goat Software. Qué miden realmente los story points y por qué confundirlos con complejidad lleva a mal uso.
• Measuring Development Productivity in the AI Era — Ministry of Programming. Análisis de métricas más allá de líneas de código y commits.
• Every Bad Developer Story Has 2 Sides — Reddit / ProgrammerHumor. Caso real de commits inflados para cumplir métricas.
• Fired by E-mail: Elon Musk Launches a Wave of Layoffs at Twitter — Le Monde. Reportaje sobre los despidos masivos en Twitter.
• Elon Musk Laid Off Twitter Engineers Based on Lines of Code — P10Y. Análisis del criterio de LOC como métrica de despido.
• Story Points Were Misused to Measure the Teams — Reddit / Agile. Caso de ingeniero sénior infravalorado por métricas superficiales.
• Elon Musk’s Twitter Layoffs Could Diminish Its Secret Sauce — Bloomberg. Impacto de los despidos en la capacidad técnica de Twitter.
• Elon Musk Posts Pictures Leaving Twitter Code Review — Business Insider. La revisión de código a la 1:30 AM como espectáculo de gestión.
• Twitter Layoffs: Elon Musk Revenue Drop — The Guardian. Impacto de los despidos en los ingresos de Twitter.
• Elon Musk Orders All Coders to Show Up — Fortune. Crónica de las últimas horas de los ingenieros en Twitter.
• CannotMeasureProductivity — Martin Fowler. Por qué medir la productividad de desarrolladores con métricas simples es fundamentalmente problemático.
• The SPACE of Developer Productivity — Forsgren, Storey et al. / ACM Queue. Framework multidimensional para entender la productividad más allá de métricas de actividad.
• DORA Research Program — Google. Investigación anual sobre rendimiento de equipos de entrega de software.
• Accelerate: The Science of Lean Software and DevOps — Forsgren, Humble, Kim (2018). El libro que popularizó las métricas DORA.
• Site Reliability Engineering: Service Level Objectives — Google SRE Book. Cómo usar SLOs como herramienta de decisión real.
• Charles Goodhart — Wikipedia. Contexto sobre el economista que formuló la ley que lleva su nombre.
• Manifiesto por el Desarrollo Ágil de Software — Los principios originales del movimiento ágil, firmados entre otros por Martin Fowler.