Glosario de métricas de ingeniería y agilidad
Los términos que los equipos de ingeniería usan para planear, estimar, medir y mejorar — definidos en lenguaje claro, con una lectura más profunda enlazada cuando existe en nuestros cursos gratuitos y blog.
34 términos · 6 secciones · Publicado en julio de 2026
Entrega y flujo
7 términosTiempo de ciclo
El tiempo de ciclo es el tiempo desde que se empieza a trabajar en un elemento hasta que ese trabajo termina: el reloj arranca cuando alguien comienza el elemento y se detiene cuando está completo. Mide la eficiencia interna del equipo, y su variación importa tanto como su promedio. Un equipo cuyos elementos van de 3 a 5 días es mucho más predecible que uno que va de 1 a 30.
Tiempo de entrega (lead time)
El tiempo de entrega (lead time) es el tiempo total desde que se solicita un trabajo hasta que se entrega al cliente. Equivale al tiempo de ciclo más el tiempo en cola, y las colas suelen representar el 80% o más. El lead time es lo que experimentan los clientes; el tiempo de ciclo es lo que el equipo controla directamente. Ambos importan, y los equipos que solo ven el tiempo de ciclo subestiman drásticamente cuánto tarda realmente la entrega.
Rendimiento (throughput)
El rendimiento (throughput) es el número de elementos de trabajo que un equipo completa por unidad de tiempo, por ejemplo ocho funcionalidades por sprint. Mide la tasa de salida y la capacidad de un sistema de entrega. A diferencia de la velocidad, el throughput cuenta elementos terminados en lugar de puntos estimados, lo que lo convierte en una cantidad medida y no adivinada.
Límite de WIP
Un límite de WIP es un tope a cuántos elementos de trabajo permite un equipo en progreso a la vez. Es la práctica más contraintuitiva de kanban: al hacer menos a la vez, terminas más en total, porque la Ley de Little vincula el tiempo de entrega directamente con la cantidad de trabajo en el sistema. Los límites de WIP son experimentos, no cálculos; empieza en algún punto y ajusta.
Ley de Little
La Ley de Little es una relación de teoría de colas, demostrada por John Little en 1961, que establece que el tiempo de entrega es igual al trabajo en progreso dividido por el rendimiento. Para cualquier sistema estable, reducir el WIP acorta el tiempo de entrega sin que nadie trabaje más rápido. Un equipo que termina 10 elementos por semana con 40 en progreso promedia 4 semanas por elemento; limitar el WIP a 20 lo reduce a la mitad, a 2.
Bloqueo
Un bloqueo es cualquier cosa que impide que un elemento de trabajo o una persona avance: una dependencia de otro equipo, una falla técnica, requisitos poco claros, recursos faltantes o un proveedor externo. Los bloqueos que no se mencionan o se discuten poco están entre los mayores asesinos de las metas del sprint, y por eso sacarlos a la luz es la parte más valiosa de cualquier standup.
Deuda técnica
La deuda técnica es el costo acumulado de tomar atajos en el código, cada “luego lo limpio” que nunca sucede. Como la deuda financiera, genera intereses: el código desordenado tarda más en cambiar, esconde bugs y frena a los nuevos integrantes del equipo. La refactorización continua es cómo los equipos pagan la deuda antes de que se convierta en una base de código inmanejable.
Estimación y planeación
4 términosPuntos de historia
Los puntos de historia son una unidad de estimación relativa que combina esfuerzo, complejidad e incertidumbre en lugar de tiempo. Una historia de 5 puntos es aproximadamente el doble de esfuerzo que una de 2, pero no necesariamente el doble de horas. Las escalas comunes incluyen Fibonacci (1, 2, 3, 5, 8, 13), potencias de 2 y tallas de camiseta, donde los saltos entre valores obligan a una elección genuina.
Velocidad
La velocidad es el número de puntos de historia que un equipo completa por sprint, usada para convertir estimaciones relativas en pronósticos. La lógica es “el clima de ayer”: un equipo que promedió 25 puntos probablemente completará cerca de 25 el próximo sprint. La velocidad es una herramienta de planeación, no una métrica de productividad; ponle metas y los equipos simplemente inflan sus estimaciones.
Planning poker
El planning poker es una técnica de estimación en la que todos estiman un elemento de trabajo en privado y lo revelan al mismo tiempo, lo que elimina el anclaje al primer número dicho en voz alta. La dispersión es la señal: un 3 unánime significa entendimiento compartido y sigues adelante, mientras que una división entre 2 y 13 significa que dos personas están imaginando trabajos fundamentalmente distintos.
Más: The Minimum Useful Estimate (Software Delivery Fundamentals)
Sprint
Un sprint es una iteración de duración fija de un mes o menos que sirve como el pulso de scrum y contiene todos los demás eventos de scrum. Los sprints corren uno tras otro sin pausas, cada uno lleva una meta de sprint que da enfoque, y cada uno debería terminar con un incremento potencialmente entregable. Una duración de sprint consistente construye ritmo y predictibilidad.
Ceremonias
5 términosRetrospectiva
Una retrospectiva es una reunión recurrente del equipo que inspecciona cómo trabajó el equipo durante el último sprint y produce un plan de mejora. Asiste solo el equipo, sin stakeholders, y el resultado es un conjunto pequeño de mejoras accionables. Es el corazón de la mejora continua: sáltatela y el equipo deja de mejorar.
Standup (daily scrum)
Un standup, llamado daily scrum en scrum, es un evento diario de 15 minutos donde los desarrolladores inspeccionan el progreso hacia la meta del sprint y adaptan el plan del día. Es coordinación, no reporte de estatus: el resultado es un plan actualizado, y los bloqueos afloran ahí pero se resuelven después, no durante la reunión.
Standup asíncrono
Un standup asíncrono es un standup que sucede sin una reunión síncrona: las actualizaciones se autogeneran desde la actividad ya registrada en herramientas como Jira, Linear, GitHub y GitLab, o se envían por escrito en el horario de cada persona. La premisa es simple: si el trabajo ya está registrado en algún lugar, los humanos no deberían tener que recitarlo.
Elemento de acción
Un elemento de acción es un compromiso específico y con responsable para cambiar algo, típicamente producido por una retrospectiva. La mayoría muere en silencio: una encuesta de la comunidad del PMI encontró que casi dos tercios de los equipos implementan menos del 25% de los elementos de acción de sus retrospectivas. Cada elemento abandonado es una pequeña promesa rota, y con suficientes promesas rotas el equipo aprende a dejar de señalar problemas.
Seguridad psicológica
La seguridad psicológica es la creencia de que puedes alzar la voz con preguntas, preocupaciones, errores o desacuerdos sin castigo ni humillación. No se trata de ser amable; se trata de habilitar la franqueza. El Proyecto Aristóteles de Google encontró que la seguridad psicológica era el predictor número uno de los equipos de alto desempeño, más importante que el talento individual.
Más: Creating Psychological Safety (Scrum Master Essentials)
Medición y métricas
10 términosMétricas DORA
Las métricas DORA son cuatro medidas del desempeño de entrega de software: frecuencia de despliegue, tiempo de entrega de cambios, tasa de fallos por cambio y tiempo medio de restauración. Provienen del programa DevOps Research and Assessment detrás de la investigación de Accelerate y los reportes anuales State of DevOps, que consistentemente encuentran que los equipos de élite entregan más rápido con menos fallos. Medidas en aislamiento, son instrumentación y no insight.
Frecuencia de despliegue
La frecuencia de despliegue es la métrica DORA que mide qué tan seguido un equipo lleva código a producción. Puede calcularse automáticamente desde pipelines de CI/CD como GitHub Actions, GitLab CI/CD y Bitbucket Pipelines. Más allá del número, es evidencia de rendimiento real: un equipo que despliega con frecuencia y calidad estable está demostrando entrega, no solo cerrando tickets.
Tiempo de entrega de cambios
El tiempo de entrega de cambios es la métrica DORA que mide cuánto tarda el código en ir del commit a correr en producción. Los tiempos largos suelen deberse a WIP alto, lotes grandes o cuellos de botella en las revisiones, más que a programar lento, así que esta métrica se lee mejor junto a las señales de flujo que ya están en tus datos de gestión de proyectos.
Tasa de fallos por cambio
La tasa de fallos por cambio es la métrica DORA que mide el porcentaje de despliegues a producción que causan un fallo que requiere remediación. Es una señal de calidad: los picos suelen correlacionarse con plazos apresurados, contribuidores nuevos o cambios de infraestructura, y por eso el número es más útil cuando se conecta con el contexto del sprint que lo explica.
Tiempo medio de recuperación (MTTR)
El tiempo medio de recuperación, o MTTR, es la métrica DORA que mide cuánto se tarda en restaurar el servicio después de un fallo en producción. Una recuperación rápida señala una respuesta a incidentes sólida y una familiaridad profunda con la base de código, y por eso el MTTR se lee como una señal de responsabilidad y operación más que como un número puro de velocidad.
Efectividad del desarrollador
La efectividad del desarrollador es una medida de si el trabajo de una persona de ingeniería crea resultados duraderos, no de cuánta actividad genera. Simyl Flow la puntúa en seis dimensiones: Entrega, Flujo, Calidad, Colaboración, Responsabilidad y Adaptabilidad. La puntuación multidimensional resiste la manipulación, y la medición se mantiene orientada a resultados: sin rastreo de teclas, sin vigilancia del uso de herramientas, y los perfiles individuales son privados por defecto.
Productividad vs. efectividad del desarrollador
La productividad y la efectividad del desarrollador son medidas distintas: la productividad cuenta actividad (commits, líneas de código, tickets cerrados) mientras que la efectividad mide resultados, si el trabajo entregado creó valor duradero. La distinción importa porque las métricas de actividad invitan a la vigilancia y la manipulación, mientras que la efectividad infiere desde los resultados en lugar de rastrear el uso de herramientas y favorece el coaching sobre el juicio.
Puntuación de salud
Una puntuación de salud es una calificación de 0 a 100, con letras de A a F, que resume la salud del sprint de un equipo en las seis dimensiones de efectividad. Su trabajo es cerrar el ciclo de mejora: después de que una retrospectiva cambia cómo trabaja el equipo, la tendencia de la puntuación de salud muestra si ese cambio realmente movió la aguja.
Ley de Goodhart
La Ley de Goodhart es la observación, nombrada por el economista británico Charles Goodhart, de que “cuando una medida se convierte en meta, deja de ser una buena medida”. En ingeniería aparece como manipulación de métricas: ponle meta a la velocidad y las estimaciones se inflan; ponle meta a las historias cerradas y el trabajo se marca como terminado antes de estarlo. El tablero sigue en verde mientras la entrega sufre.
Métricas de vanidad
Las métricas de vanidad son números que suben sin correlacionar con resultados de negocio: commits por día, líneas de código, puntos de historia completados, PRs fusionados. Son tentadoras porque son fáciles de recolectar y hacen gráficas satisfactorias, pero crean incentivos perversos y una ilusión de visibilidad. La prueba: si este número se duplica, ¿se duplica el valor de negocio?
Métodos
5 términosScrum
Scrum es un marco ágil ligero para desarrollar productos complejos, fundado en el empirismo: transparencia, inspección y adaptación. Define tres roles (product owner, scrum master, desarrolladores), cinco eventos incluidos el sprint y la retrospectiva, y tres artefactos. La Guía de Scrum tiene solo 13 páginas porque scrum es intencionalmente incompleto: un marco con barandales, no una metodología paso a paso.
Kanban
Kanban es un método adaptativo para gestionar trabajo del conocimiento que visualiza el flujo de trabajo, limita el trabajo en progreso y evoluciona el proceso de forma incremental. Su filosofía es “empieza donde estás”: sin roles prescritos, sin eventos obligatorios, sin iteraciones fijas. Nació del Sistema de Producción de Toyota y fue adaptado al software por David J. Anderson en los años 2000.
Extreme Programming (XP)
Extreme Programming (XP) es una metodología ágil, establecida por el libro de Kent Beck de 1999 Extreme Programming Explained, que es prescriptiva sobre la práctica de ingeniería donde scrum guarda silencio: escribe pruebas primero, programa en pareja, refactoriza continuamente e integra muchas veces al día. Sus cinco valores son comunicación, simplicidad, retroalimentación, coraje y respeto.
Programación en pareja
La programación en pareja es dos desarrolladores trabajando juntos en una estación: uno teclea (el conductor) mientras el otro observa, piensa por adelantado y navega. La investigación citada en la literatura de XP encuentra que las parejas producen código con aproximadamente 15% menos defectos tomando solo cerca de 15% más de tiempo, en efecto revisión de código continua más conocimiento esparciéndose por el equipo.
Desarrollo guiado por pruebas (TDD)
El desarrollo guiado por pruebas (TDD) es la práctica de escribir una prueba que falla antes de escribir el código de producción, repetida en un ciclo rojo-verde-refactor: escribe una prueba que falla, escribe el mínimo código para que pase y luego limpia mientras las pruebas siguen en verde. TDD es una técnica de diseño disfrazada de técnica de pruebas; el pensamiento que produce las pruebas es el punto.
IA y herramientas
3 términosMCP (Model Context Protocol)
MCP, el Model Context Protocol, es un protocolo abierto que permite a asistentes de IA como Claude y ChatGPT conectarse directamente a herramientas y fuentes de datos externas. Simyl Flow expone 17 herramientas MCP de solo lectura en 8 dominios, cubriendo standups, retrospectivas, métricas y elementos de acción, para que los asistentes de IA que un equipo adopta puedan consultar si realmente están ayudando.
Workflow exhaust
El workflow exhaust son los datos estructurados que tus herramientas existentes ya emiten como efecto secundario del trabajo normal: historial de commits, revisiones de PRs, transiciones de tickets y ejecuciones de pipelines de CI/CD. El principio detrás del término: los datos necesarios para medir la entrega ya existen; el problema nunca fue la disponibilidad, sino que estaban en silos desconectados del contexto que los hace significativos.
Ship and stick
Ship and stick es un marco de medición que hace dos preguntas sobre cualquier cambio en cómo trabaja un equipo, sea una nueva herramienta, proceso o asistente de IA: ¿el trabajo se entregó, y siguió creando valor en producción? Sus signos vitales incluyen la tasa de retrabajo (reverts y hotfixes), la trayectoria de calidad en el tiempo y la predictibilidad de la entrega, leídos en conjunto y no en aislamiento.
Las definiciones son la parte fácil
Saber qué significa tiempo de ciclo no es lo mismo que conocer el tuyo. Simyl Flow calcula estas métricas desde las herramientas que tu equipo ya usa y muestra si tus cambios están funcionando.