Preguntas de Entrevista sobre Metricas DevOps, Agile y Scrum: DORA, Velocidad y EVM (2026)

Las metricas de gestion de proyectos son esenciales para medir el rendimiento del equipo, identificar cuellos de botella e impulsar la mejora continua. Esta guia cubre metricas clave en metodologias DevOps, Agile, Scrum y gestion de proyectos tradicional, junto con preguntas comunes de entrevista que encontraras en roles de ingenieria senior y gestion.

Metricas DevOps (DORA Metrics)

Las metricas DORA (DevOps Research and Assessment) son el estandar de oro para medir el rendimiento de DevOps:

1. Frecuencia de Despliegue

Que mide: Con que frecuencia tu equipo despliega codigo a produccion.

Nivel de Rendimiento	Frecuencia
Elite	Bajo demanda (multiples veces al dia)
Alto	Semanal a mensual
Medio	Mensual a cada 6 meses
Bajo	Menos de una vez cada 6 meses

Pregunta de Entrevista: "Tu equipo despliega una vez al mes. Que pasos tomarias para aumentar la frecuencia de despliegue?"

Respuesta Solida: "Comenzaria analizando que esta bloqueando despliegues mas frecuentes. Los problemas comunes incluyen: cuellos de botella en pruebas manuales (implementar pruebas automatizadas), tamanos de lote grandes (dividir el trabajo en incrementos mas pequenos), falta de automatizacion CI/CD (invertir en infraestructura de pipeline), y miedo a los despliegues (implementar feature flags y rollbacks automatizados). Mediria el tiempo de ciclo actual, identificaria la restriccion mas grande y enfocaria los esfuerzos de mejora ahi."

2. Lead Time for Changes

Que mide: Tiempo desde el commit de codigo hasta el despliegue a produccion.

Nivel de Rendimiento	Lead Time
Elite	Menos de 1 hora
Alto	1 dia a 1 semana
Medio	1 semana a 1 mes
Bajo	Mas de 1 mes

Pregunta de Entrevista: "Como reducirias el lead time de 2 semanas a 2 dias?"

Respuesta Solida: "Mapearia el flujo de valor para identificar tiempos de espera vs. tiempos de trabajo. Tipicamente, la mayor parte del lead time es espera—por revision de codigo, aprobacion de QA, ventanas de despliegue. Las soluciones incluyen: implementar trunk-based development, automatizar puertas de revision de codigo, pruebas en paralelo y habilitar despliegues de autoservicio. Configuraria dashboards de metricas para rastrear cada etapa y me enfocaria en eliminar los tiempos de espera mas largos primero."

3. Mean Time to Recovery (MTTR)

Que mide: Tiempo promedio para restaurar el servicio despues de un incidente.

Nivel de Rendimiento	MTTR
Elite	Menos de 1 hora
Alto	Menos de 1 dia
Medio	1 dia a 1 semana
Bajo	Mas de 1 semana

Pregunta de Entrevista: "El MTTR de tu equipo es de 8 horas. Como lo reducirias a menos de 1 hora?"

Respuesta Solida: "La recuperacion rapida requiere: deteccion rapida (monitoreo y alertas integrales), diagnostico rapido (logging centralizado, tracing distribuido, runbooks), y remediacion rapida (rollbacks automatizados, feature flags, infraestructura como codigo). Implementaria rotaciones de guardia con rutas de escalacion claras, conduciria simulacros regulares de respuesta a incidentes, y aseguraria que cada incidente tenga un post-mortem sin culpas para prevenir recurrencia."

4. Change Failure Rate

Que mide: Porcentaje de despliegues que causan fallos en produccion.

Nivel de Rendimiento	Tasa de Fallos
Elite	0-15%
Alto	16-30%
Medio	31-45%
Bajo	46-60%

Pregunta de Entrevista: "El 30% de tus despliegues fallan. Cual es tu plan de mejora?"

Respuesta Solida: "Las altas tasas de fallo indican problemas de calidad mas temprano en el pipeline. Implementaria: pruebas automatizadas integrales (unitarias, integracion, e2e), entornos de staging que reflejen produccion, despliegues canary para detectar problemas temprano, y practicas mejoradas de revision de codigo. Tambien analizaria los despliegues fallidos para identificar patrones—son los fallos de servicios especificos, equipos o tipos de cambios? Luego apuntaria a las causas raiz."

Metricas Agile

Velocity

Que mide: Story points completados por sprint.

Velocity = Sum of story points completed in sprint

Example:
Sprint 1: 21 points
Sprint 2: 24 points
Sprint 3: 18 points
Average Velocity: 21 points

Pregunta de Entrevista: "Un stakeholder te pide comprometerte con 40 story points en el proximo sprint cuando tu velocity promedio es 25. Como respondes?"

Respuesta Solida: "Explicaria que velocity es una herramienta de planificacion, no un objetivo de rendimiento. Comprometerse con 40 puntos probablemente resultaria en trabajo incompleto o atajos de calidad. En cambio, discutiria: priorizar los 25 puntos de trabajo mas valiosos, identificar si hay bloqueadores que podriamos remover para aumentar velocity de manera sostenible, o si necesitamos mas capacidad de equipo. Inflar compromisos destruye la confianza y la previsibilidad."

Sprint Burndown

Que mide: Trabajo restante a lo largo del sprint.

Pregunta de Entrevista: "Tu grafico de burndown muestra que el trabajo aumenta a mitad del sprint. Que indica esto y como lo abordas?"

Respuesta Solida: "El aumento de trabajo a mitad del sprint senala scope creep o mala estimacion. Investigaria: Se estan agregando requisitos despues del planning del sprint? Estan las historias mal definidas, requiriendo mas trabajo del estimado? Se esta descubriendo deuda tecnica? Las soluciones incluyen: practicas mas estrictas de compromiso de sprint, mejor refinamiento de historias, y dividir historias grandes. Tambien facilitaria una discusion de equipo para entender el patron."

Cumulative Flow Diagram

Que mide: Items de trabajo en cada etapa a lo largo del tiempo.

Pregunta de Entrevista: "Tu diagrama de flujo acumulativo muestra una banda de 'In Progress' que se ensancha. Que esta pasando?"

Respuesta Solida: "Una banda que se ensancha indica un cuello de botella—el trabajo esta entrando a esa etapa mas rapido de lo que sale. Para 'In Progress,' esto tipicamente significa demasiado WIP (work in progress). Implementaria limites de WIP para forzar la finalizacion antes de comenzar nuevo trabajo, identificaria por que los items estan atascados (esperando revision, dependencias bloqueadas), y potencialmente concentraria esfuerzos en items para limpiar el backlog. El objetivo es un flujo suave, no maximizar inicios."

Cycle Time

Que mide: Tiempo desde que el trabajo comienza hasta que se completa.

Cycle Time = Completion Date - Start Date

Example:
Story started: Monday 9am
Story completed: Wednesday 3pm
Cycle Time: 2.25 days

Pregunta de Entrevista: "El cycle time promedio de tu equipo es de 8 dias para historias. Como lo reducirias?"

Respuesta Solida: "Analizaria donde se gasta el tiempo. A menudo es: esperando revision de codigo (implementar revisiones asincronas, pair programming), esperando QA (shift-left testing, calidad propiedad del desarrollador), cambio de contexto (limitar WIP), y tamano de historia grande (dividir historias mas pequenas). Visualizaria el flujo de trabajo, mediria el tiempo en cada etapa, y atacaria sistematicamente los mayores retrasos. Historias mas pequenas casi siempre reducen el cycle time."

Metricas Especificas de Scrum

Tasa de Exito del Sprint Goal

Que mide: Porcentaje de sprints donde se logra el sprint goal.

Pregunta de Entrevista: "Tu equipo logra los sprint goals solo el 40% del tiempo. Como mejoras esto?"

Respuesta Solida: "El bajo logro de objetivos sugiere problemas con planificacion, alcance o ejecucion. Examinaria: Son los objetivos demasiado ambiciosos? Esta el alcance creciendo a mitad del sprint? Hay dependencias externas causando retrasos? Las soluciones incluyen: crear sprint goals enfocados y alcanzables; proteger el sprint de cambios de alcance; mejorar la estimacion con planning poker; y asegurar que las historias esten verdaderamente 'listas' antes del sprint planning. El equipo tambien deberia reflexionar sobre esto en las retrospectivas."

Predictabilidad del Sprint

Predictability = (Completed Points / Committed Points) × 100%

Target: 80-100%

Example:
Committed: 30 points
Completed: 24 points
Predictability: 80%

Pregunta de Entrevista: "Como equilibras la predictabilidad con la ambicion en el sprint planning?"

Respuesta Solida: "Usaria yesterday's weather—comprometerse con lo que realmente entregamos en sprints recientes, no con lo que esperamos entregar. Esto construye confianza con los stakeholders a traves de la fiabilidad. Para la ambicion, identificaria stretch goals que son valiosos si se completan pero no comprometidos. Con el tiempo, a medida que el equipo mejora procesos y remueve impedimentos, la velocity sostenible aumenta naturalmente. La predictabilidad permite una mejor planificacion de negocio."

Tasa de Escape de Defectos

Que mide: Bugs encontrados en produccion vs. encontrados durante desarrollo.

Defect Escape Rate = (Production Bugs / Total Bugs Found) × 100%

Target: < 10%

Pregunta de Entrevista: "El 40% de los bugs se estan encontrando en produccion. Cual es tu estrategia de calidad?"

Respuesta Solida: "Las altas tasas de escape indican problemas de calidad en nuestro proceso de desarrollo. Implementaria: definicion de done que incluya requisitos de prueba, pruebas automatizadas en multiples niveles (unitarias, integracion, e2e), checklists de revision de codigo que incluyan cobertura de pruebas, e involucramiento de QA mas temprano en el proceso. Tambien analizaria los defectos escapados para encontrar patrones—estan en areas especificas, de ciertos tipos de cambios, o escenarios de prueba faltantes?"

Metricas de Gestion de Proyectos Tradicional

Earned Value Management (EVM)

Key EVM Metrics:

Planned Value (PV) = Budgeted cost of scheduled work
Earned Value (EV) = Budgeted cost of completed work
Actual Cost (AC) = Actual cost of completed work

Schedule Variance (SV) = EV - PV
  Positive = ahead of schedule
  Negative = behind schedule

Cost Variance (CV) = EV - AC
  Positive = under budget
  Negative = over budget

Schedule Performance Index (SPI) = EV / PV
  > 1.0 = ahead of schedule
  < 1.0 = behind schedule

Cost Performance Index (CPI) = EV / AC
  > 1.0 = under budget
  < 1.0 = over budget

Pregunta de Entrevista: "Tu proyecto tiene SPI de 0.8 y CPI de 0.9. Interpreta esto y recomienda acciones."

Respuesta Solida: "SPI 0.8 significa que estamos entregando el 80% del trabajo planificado—estamos atrasados en cronograma. CPI 0.9 significa que estamos gastando mas de lo presupuestado para el trabajo completado—estamos sobre presupuesto. El proyecto esta en problemas en ambas dimensiones. Yo: reevaluaria el alcance restante para identificar que se puede cortar o diferir, investigaria por que la productividad esta por debajo del plan (problemas de recursos, cambios de requisitos, problemas tecnicos), reajustaria las expectativas de los stakeholders con pronosticos revisados, e implementaria controles mas estrictos en el trabajo restante."

Utilizacion de Recursos

Utilization Rate = (Billable Hours / Available Hours) × 100%

Target varies by role:
- Developers: 70-80% (need slack for learning, meetings)
- Consultants: 80-90% (billable target)
- Managers: 50-60% (coordination overhead)

Pregunta de Entrevista: "La utilizacion de tu equipo esta al 95%. Es bueno o malo?"

Respuesta Solida: "Una utilizacion del 95% es en realidad preocupante. Significa que el equipo casi no tiene margen para: manejar problemas inesperados, reduccion de deuda tecnica, aprendizaje y mejora, ayudar a companeros de equipo, o innovacion. La alta utilizacion lleva al agotamiento, problemas de calidad e incapacidad para absorber cualquier variacion. Apuntaria a 70-80% para un rendimiento sostenible, usando la capacidad restante para trabajo de mejora y manejar la variabilidad normal."

Entrega a Tiempo

On-Time Delivery Rate = (Projects Delivered On Time / Total Projects) × 100%

Pregunta de Entrevista: "Solo el 50% de tus proyectos se entregan a tiempo. Como mejoras esto?"

Respuesta Solida: "Analizaria por que los proyectos se retrasan: scope creep, mala estimacion, restricciones de recursos o dependencias externas. Las soluciones incluyen: mejor recopilacion de requisitos inicial, tecnicas de estimacion que consideren la incertidumbre (PERT, Monte Carlo), gestion de buffer, procesos claros de control de cambios, e identificacion mas temprana de riesgos. Tambien examinaria si las fechas limite se estan estableciendo de manera realista basado en alcance y recursos, o si son objetivos arbitrarios."

Metricas de Salud del Equipo

Moral del Equipo / eNPS

Que mide: Satisfaccion del empleado y probabilidad de recomendar el lugar de trabajo.

Pregunta de Entrevista: "El eNPS de tu equipo cayo de +30 a -10 en dos trimestres. Como investigas y abordas esto?"

Respuesta Solida: "Esta es una caida significativa que requiere atencion inmediata. Yo: conduciria reuniones 1:1 para entender las preocupaciones individuales, ejecutaria una encuesta anonima para identificar problemas especificos, examinaria que cambio (nuevo liderazgo, presiones de proyecto, cambios de proceso), y miraria metricas adyacentes (rotacion, dias de enfermedad). Una vez identificadas las causas raiz, crearia un plan de accion, comunicaria transparentemente sobre lo que estamos haciendo para mejorar, y haria seguimiento regularmente. Los problemas de moral dejados sin abordar se multiplican rapidamente."

Tiempo de Respuesta de Code Review

Average Review Time = Sum of (Review Complete - PR Opened) / Number of PRs

Target: < 24 hours for first review

Pregunta de Entrevista: "Las revisiones de codigo estan tomando 3 dias en promedio. Como impacta esto al equipo y como lo arreglarias?"

Respuesta Solida: "Las revisiones lentas causan cambio de contexto (los desarrolladores pasan a nuevo trabajo y luego deben regresar), cycle times mas largos, lotes de revision mas grandes (haciendo las revisiones mas dificiles), y frustracion. Implementaria: SLAs para tiempos de respuesta de revision, tamanos de PR mas pequenos, pairing para reducir la necesidad de revision, rotacion de deberes de revision, bloques de tiempo dedicados a revision, y herramientas que muestren PRs estancados. El objetivo son ciclos de retroalimentacion rapidos."

Anti-Patrones de Metricas

Errores Comunes

Pregunta de Entrevista: "Cuales son los peligros de medir la productividad individual del desarrollador?"

Respuesta Solida: "Medir individuos crea incentivos perversos: manipular metricas (inflar story points, rellenar commits), colaboracion reducida (ayudar a otros perjudica tus numeros), y seleccionar trabajo facil. Ignora que el desarrollo de software es un deporte de equipo—los mejores desarrolladores a menudo hacen a otros mas productivos a traves de mentoria, decisiones de arquitectura y desbloquear trabajo. Mediria resultados de equipo y metricas de flujo en lugar de output individual."

Ley de Goodhart

"Cuando una medida se convierte en objetivo, deja de ser una buena medida."

Pregunta de Entrevista: "Como previenes que las metricas sean manipuladas?"

Respuesta Solida: "Usaria multiples metricas complementarias que son dificiles de manipular simultaneamente—por ejemplo, tanto velocity COMO metricas de calidad. Me enfocaria en metricas de resultado (satisfaccion del cliente, resultados de negocio) en lugar de metricas de actividad (lineas de codigo, PRs mergeados). Trataria las metricas como herramientas de diagnostico para mejora, no objetivos de rendimiento. Y rotaria regularmente cuales metricas enfatizamos para prevenir la manipulacion de cualquier medida individual."

Construyendo un Dashboard de Metricas

Recommended Metrics by Role:

Engineering Manager:
- DORA metrics (deployment frequency, lead time, MTTR, change failure rate)
- Sprint predictability
- Team capacity utilization
- Code review turnaround
- Defect escape rate

Product Manager:
- Velocity/throughput
- Cycle time
- Sprint goal success rate
- Customer-reported issues
- Feature adoption rates

Executive/Stakeholder:
- On-time delivery rate
- Budget variance
- Team satisfaction (eNPS)
- Customer satisfaction (NPS)
- Business outcome metrics

Conclusion

Las metricas efectivas impulsan la mejora cuando se usan de manera reflexiva. Enfocate en scorecards balanceados que midan multiples dimensiones, enfatiza los resultados del equipo sobre el output individual, y recuerda que las metricas son herramientas para aprender y mejorar—no armas para culpar. En entrevistas, demuestra que entiendes tanto que medir como las dinamicas humanas alrededor de la medicion.