Métricas de ingeniería sin Jira
No necesitas Jira para medir lo que importa. Cómo rastrear la salud del equipo de ingeniería desde Git, CI y las herramientas que ya utilizas.
By Ellis Keane · 2026-03-23
Los equipos pequeños que obtienen la mejor visibilidad de ingeniería suelen ser los que dejaron de perseguir las métricas que Jira quiere que rastreen.
Me doy cuenta de que eso suena como si simplemente estuviera siendo contrario por serlo – y honestamente, puede que lo sea un poco. Pero pasé casi tres años manteniendo fielmente tableros de sprint, depurando backlogs y actualizando estimaciones en tickets que ya estaban a medio terminar antes de que alguien abriera Jira esa mañana. Cada dos semanas nos sentábamos en una sala (bueno, un Zoom – era 2023) y mirábamos un gráfico de velocity que no nos decía absolutamente nada que ya no supiéramos hablando entre nosotros. Las métricas de ingeniería sin Jira no era algo que estuviera buscando. Fue lo que ocurrió cuando dejé de fingir que los gráficos de velocity me decían algo útil.
Si tu equipo es lo suficientemente pequeño como para sentarse alrededor de una mesa, probablemente no necesites Jira para saber cómo os va. Necesitas mejores señales de las herramientas que ya estás usando.
Esto no es un artículo sobre "Jira es malo". Jira es una buena herramienta para organizaciones que necesitan el seguimiento con forma de Jira (y a cierta escala, genuinamente lo necesitan). Pero si eres un engineering manager en una startup de 10 a 40 personas, pagar por Jira únicamente para producir gráficos de velocity es un poco como comprar un horno industrial para recalentar tu almuerzo.
"Pagar por Jira únicamente para producir gráficos de velocity es un poco como comprar un horno industrial para recalentar tu almuerzo." attribution: Chris Calo
Qué miden realmente las métricas de Jira
Seré directo: la mayoría de las métricas de Jira miden el uso de Jira, no el output de ingeniería. Los story points miden la capacidad del equipo para estimar story points. La velocity mide la consistencia con que el equipo llena los sprints hasta aproximadamente la misma capacidad. Los gráficos de burndown miden si alguien recordó arrastrar tickets por el tablero el jueves por la tarde.
Ninguna de estas es completamente inútil. Pero son métricas de proceso disfrazadas de métricas de productividad de desarrolladores, y la brecha entre ambas es donde los engineering managers pierden el hilo.
He sido el EM que pasa casi una hora antes de una reunión con stakeholders ajustando datos de Jira para una presentación que muestra "estamos en camino". El stakeholder asiente, hace una pregunta sobre el bug de inicio de sesión del martes pasado, y la reunión termina. La hora fue para la presentación. La respuesta real era "pregúntale al ingeniero".
Si tus métricas requieren más mantenimiento que el trabajo que miden, las métricas son el problema.
Tiempo de ciclo desde Git, no desde tableros de tickets
Para equipos de producto pequeños, el tiempo de ciclo suele ser la métrica con mayor señal que puedes rastrear. Mide la duración desde el primer commit hasta el despliegue en producción, y puedes derivarla completamente de tu historial de Git y pipeline de CI – sin necesidad de tablero de tickets.
Los componentes:
- Timestamp del primer commit en un branch o PR
- Timestamp del merge del PR
- Timestamp del despliegue (de tu CI/CD – GitHub Actions, CircleCI, lo que estés usando)
El delta entre 1 y 3 es tu tiempo de ciclo. Divídelo en segmentos – tiempo de codificación (del 1 a la apertura del PR), tiempo de revisión (apertura del PR al merge) y cola de despliegue (merge a producción) – y tendrás un diagnóstico que te dice dónde se estanca realmente el trabajo.
Cuando hice esto por primera vez para nuestro equipo, los números fueron genuinamente sorprendentes. Había asumido que el tiempo de revisión era nuestro cuello de botella (todos siempre asumen que el tiempo de revisión es el cuello de botella, ¿verdad?). Resultó que nuestra fase de codificación hasta PR estaba bien, las revisiones estaban bien, y estábamos perdiendo unos dos días de promedio entre el merge y el despliegue porque nuestro entorno de staging era inestable y nadie había priorizado arreglarlo. Un gráfico de velocity nunca habría revelado eso.
Cómo medirlo
Si usas GitHub, puedes obtener esto con la CLI:
```bash
Obtener PRs fusionados en los últimos 30 días
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Para los timestamps de despliegue, la mayoría de los sistemas de CI los exponen a través de API o webhook. Mapea los SHAs de merge de PR a los eventos de despliegue, y tendrás el tiempo de ciclo segmentado por fase.
Consejo: Si tu CI no expone timestamps de despliegue con claridad, un enfoque muy simple es un bot de Slack que publique en un canal #deploys con el SHA del commit. Obtienes timestamps, un registro legible por humanos y – como efecto secundario – un canal que te dice con qué frecuencia estás desplegando.
Rendimiento de revisiones de código
El rendimiento de revisiones – el número de PRs revisados por ingeniero por semana y el tiempo medio desde la apertura del PR hasta la primera revisión – dice más sobre la salud del equipo que cualquier métrica de sprint. Está infravalorado.
¿Por qué? Porque el comportamiento en revisiones es un indicador adelantado. Cuando los tiempos de revisión aumentan, suele significar que los ingenieros están sobrecargados, haciendo demasiado cambio de contexto, o – y este es el incómodo – evitando el código de los demás. Cualquiera de esos vale la pena saberlo antes de que aparezca como un plazo incumplido dos semanas después.
GitHub te proporciona estos datos a través de su API. Los campos clave son createdAt en el PR y submittedAt en el primer evento de revisión.
El número que observo es las horas medianas hasta la primera revisión. Según nuestra experiencia en varios equipos pequeños, una cadencia de revisión saludable tiende a mantenerse por debajo de unas 8 horas. Cuando supera un día de forma consistente, algo estructural ha cambiado – y lo que sea que sea, es invisible en Jira.
La proporción reuniones-a-decisiones
Esta no es una métrica de ingeniería tradicional, y debo ser honesto: es una heurística aproximada, no un KPI. Pero para equipos pequeños, la encuentro sorprendentemente reveladora.
Cuenta las reuniones que tu equipo tuvo esta semana. Cuenta las decisiones concretas que salieron de ellas (no "deberíamos investigar X" – decisiones reales con propietarios y próximos pasos). Divide lo segundo entre lo primero.
Si menos de la mitad de tus reuniones produjeron una decisión, vale la pena preguntarse si esas reuniones están justificando su tiempo. Algunas reuniones existen para reducir riesgos o compartir contexto, y eso es legítimo – no todo necesita terminar con una resolución. Pero cuando empiezas a rastrear esto aunque sea informalmente (literalmente llevé un recuento en mi cuaderno), desarrollas un sentido para qué reuniones son generativas y cuáles son solo rituales que nadie ha cuestionado.
Rastreé esto durante aproximadamente un mes, y cambió la forma en que programaba reuniones más que cualquier artículo de productividad. Cuando puedes ver que tu standup del lunes ha producido exactamente cero decisiones en tres semanas consecutivas, cancelarlo deja de parecer radical.
Construir métricas de ingeniería sin Jira: un dashboard ligero
No necesitas una herramienta de BI para esto. Una página de Notion, una hoja de Google o un post semanal de Slack con cuatro números es suficiente:
- Tiempo de ciclo medio (de Git/CI) – ¿estamos desplegando más rápido o más lento?
- Tiempo medio hasta la primera revisión (de GitHub) – ¿está el equipo revisando con prontitud?
- Frecuencia de despliegue (de CI o canal #deploys) – ¿con qué frecuencia desplegamos?
- Proporción reuniones-a-decisiones (recuento manual) – ¿están justificando su tiempo nuestras reuniones?
Cuatro números, todos derivables de herramientas que ya tienes, ninguno de los cuales requiere mantener un tablero de Jira. Actualízalos semanalmente. Si un número se mueve en la dirección equivocada durante dos semanas consecutivas, investiga. Si se mantiene estable, déjalo.
El objetivo no es construir un sistema de vigilancia (por favor no lo hagas – tus ingenieros te odiarán, y tendrán razón). La visibilidad del equipo de ingeniería debería provenir del trabajo en sí, no de pedir a las personas que informen sobre el trabajo.
Las mejores métricas de ingeniería son baratas de recopilar, difíciles de manipular y te dicen algo sobre lo que puedes actuar. Los story points fracasan en los tres puntos.
Cuándo sí necesitas un tablero de tickets
Dije que esto no es un artículo sobre "Jira es malo", y lo dije en serio. Hay situaciones legítimas en las que rastrear métricas sin una herramienta de gestión de proyectos se vuelve genuinamente irresponsable:
- Industrias con alta carga de cumplimiento normativo donde los rastros de auditoría sobre el estado de las tareas son legalmente requeridos
- Organizaciones de ingeniería más grandes donde las dependencias entre equipos hacen que la coordinación informal sea insostenible
- Organizaciones con funciones de gestión de proyectos dedicadas que necesitan una fuente canónica de verdad entre equipos
Si esa es tu situación, Jira (o Linear, o Shortcut) es la elección correcta. Lo que argumento es que para equipos pequeños, mantener una herramienta pesada únicamente para métricas es un mal intercambio. Terminas optimizando para el modelo de trabajo de la herramienta en lugar del trabajo real de tu equipo.
¿Y honestamente? Incluso los equipos que usan Jira se beneficiarían de complementar los datos de su tablero con las métricas derivadas de Git mencionadas anteriormente. Jira te dice lo que la gente dice que está haciendo. Git te dice lo que realmente están haciendo. Ambos son útiles, pero solo uno es inmune al teatro de actualizaciones de estado.
Si la pregunta de las métricas sigue surgiendo en tu startup, prueba el dashboard de cuatro números durante un mes. Las métricas de ingeniería sin Jira pueden sonar como trabajar sin red de seguridad – pero una vez que ves cuánta señal vive en tu historial de Git y pipeline de CI, te preguntarás qué estaba aportando el tablero de tickets.
Descubre automáticamente el tiempo de ciclo, las PRs bloqueadas y los cuellos de botella en revisiones – sin scripts personalizados ni un tablero de Jira.
Q: ¿Se pueden obtener métricas de ingeniería significativas sin una herramienta de gestión de proyectos? A: Sí. El tiempo de ciclo (primer commit hasta despliegue), el rendimiento de revisiones y la frecuencia de despliegue viven en tu historial de Git y pipeline de CI. Para equipos de menos de 40 ingenieros, estas tienden a ser más precisas y difíciles de manipular que cualquier cosa que produzca un tablero de tickets – y no requieren que nadie arrastre tarjetas por un tablero para mantenerse precisas.
Q: ¿Sugarbug muestra métricas de ingeniería automáticamente? A: Sugarbug se conecta a GitHub, Linear, Slack y calendarios para construir un grafo de conocimiento de la actividad de tu equipo. Señala patrones como PRs bloqueadas, cuellos de botella en revisiones y decisiones sin resolver – lo que cubre muchas de las señales descritas aquí sin requerir que escribas y mantengas scripts personalizados contra la API de GitHub.
Q: ¿Cómo consigo aceptación para dejar de usar Jira para métricas? A: Preséntalo como un experimento, no como una revuelta. Ejecuta métricas derivadas de Git junto a tus dashboards de Jira existentes durante cuatro semanas, luego compara qué números impulsaron cambios reales. Si las métricas de Git resultan más accionables (y según nuestra experiencia, tienden a serlo), el caso se hace solo.
Q: ¿Cuál es la diferencia entre métricas de proceso y métricas de rendimiento? A: Las métricas de proceso (story points, velocity, burndown) miden la consistencia de un equipo siguiendo un flujo de trabajo. Las métricas de rendimiento (tiempo de ciclo, frecuencia de despliegue, rendimiento de revisiones) miden lo que el equipo realmente entrega y con qué rapidez. Los equipos pequeños casi siempre obtienen más señal de las últimas, porque las métricas de rendimiento se derivan del trabajo en sí en lugar de actualizaciones de estado manuales.