Las métricas DORA dicen más de tu equipo que la velocidad del sprint
Todas las planificaciones de sprint a las que he asistido repiten el mismo ritual. Alguien proyecta el gráfico de velocidad, el equipo debate si los 42 puntos del último sprint fueron "buenos" y todo el mundo se compromete a llegar a 45 esta vez. Dos semanas después, el ciclo vuelve a empezar. Nadie hace la pregunta que de verdad importa: ¿estamos mejorando a la hora de entregar software?
La velocidad mide actividad. No dice nada sobre si esos puntos se tradujeron en valor, si el código fue estable o si el equipo está progresando. He visto equipos con una velocidad disparada que eran incapaces de sacar a producción una funcionalidad fiable. Y equipos pequeños, con un throughput modesto, que desplegaban con confianza varias veces al día y casi sin incidentes.
¿La diferencia? El segundo grupo medía las métricas DORA.
Cuatro métricas que miden entrega, no actividad
En 2018, Nicole Forsgren, Jez Humble y Gene Kim publicaron Accelerate: The Science of Lean Software and DevOps. El libro destila años de investigación en cuatro métricas que predicen el rendimiento en la entrega de software. No son opiniones: son indicadores respaldados por datos y validados en miles de organizaciones.
Frecuencia de despliegue — con qué frecuencia tu equipo despliega a producción. Los equipos de élite despliegan bajo demanda, varias veces al día. Los de bajo rendimiento, una vez al mes o menos. Esta métrica captura tu capacidad de lanzar cambios pequeños e incrementales en lugar de releases gigantes y arriesgadas.
Lead time de los cambios — el tiempo desde que el código se commitea hasta que está corriendo en producción. Equipos de élite: menos de una hora. Bajo rendimiento: de uno a seis meses. Cada cuello de botella de tu pipeline — revisión de código, CI/CD, pruebas, aprobaciones — aparece aquí.
Tiempo medio de recuperación (MTTR) — cuando producción se rompe, ¿cuánto tardáis en arreglarlo? Los equipos de élite se recuperan en menos de una hora. Los de bajo rendimiento tardan una semana o más. Esto refleja directamente tu monitorización, tus alertas y tu respuesta a incidentes.
Tasa de fallo de los cambios — qué porcentaje de despliegues provoca un fallo en producción. Los equipos de élite se mantienen entre el 0 y el 15%. Los de bajo rendimiento superan el 46%. Aquí se ve la calidad del código, la cobertura de pruebas y la fiabilidad del pipeline.
El hallazgo contraintuitivo: velocidad y estabilidad no están reñidas. Los equipos con mejor rendimiento son a la vez los más rápidos y los más estables. Despliegan con más frecuencia, se recuperan antes y rompen menos.
Por qué la velocidad te falla
Es un número relativo e interno. Los story points significan cosas distintas en cada equipo. Una velocidad de 60 no te dice nada sin un contexto profundo sobre qué representan esos puntos. No existe un benchmark externo.
Incentiva el comportamiento equivocado. Cuando dirección vigila la velocidad, los equipos optimizan para ella. Inflan las estimaciones, trocean historias para engordar el recuento y evitan refactorizar porque no produce puntos "visibles". La métrica se convierte en objetivo, y cuando una métrica se convierte en objetivo, deja de ser una buena métrica: la ley de Goodhart.
Mide producción, no resultados. ¿Un sprint en el que el equipo quema 50 puntos pero tiene producción rota dos días? Para la velocidad, un sprint estupendo. Para DORA, un desastre.
Puedes empezar a medirlas esta misma semana
No necesitas ninguna plataforma. Empieza por lo simple.
Frecuencia de despliegue. Cuenta los despliegues a producción por semana en los logs de tu CI/CD. Si despliegas menos de una vez a la semana, tus releases son demasiado grandes, tus ramas viven demasiado tiempo o tu proceso de despliegue es demasiado penoso.
Lead time de los cambios. Timestamp del merge commit menos el primer commit de la rama. Si supera la semana, localiza la restricción: ¿retrasos en la revisión de código? ¿Una CI lenta? ¿Un cuello de botella de QA manual?
MTTR. Registra los incidentes de producción: cuándo se detectaron, cuándo se resolvieron. Hasta una hoja de cálculo sirve. Apunta a menos de 24 horas al principio; menos de una hora es nivel de élite.
Tasa de fallo de los cambios. Despliegues que causaron incidentes dividido entre despliegues totales. Por debajo del 15% es élite. Por encima del 30%, tu pipeline de pruebas tiene agujeros.
La conversación cambia
Cuando los equipos pasan a las métricas DORA, las conversaciones cambian de naturaleza. En lugar de "¿hemos cumplido el compromiso del sprint?", se preguntan "¿por qué se disparó nuestro lead time la semana pasada?". En lugar de discutir si una historia son 3 puntos o 5, los ingenieros investigan por qué falló el despliegue del jueves.
Las métricas DORA son indicadores adelantados. Una tasa de fallo al alza te avisa antes de la próxima caída. Un lead time creciente señala un cuello de botella antes de que se convierta en crisis. La velocidad es, en el mejor de los casos, un indicador retrasado del esfuerzo; en el peor, una métrica de vanidad.
Los story points pueden seguir siendo útiles para planificar el sprint dentro de un equipo. Pero nunca deberían ser la métrica que reportas a dirección, la que usas para comparar equipos ni la que tratas como salud de la ingeniería. Para eso está DORA.
Cómo hacer que cuaje
Mide las cuatro métricas cada semana. Ponlas en un dashboard visible. Comenta las tendencias en las retros. Fija objetivos direccionales: "lead time por debajo de 3 días este trimestre" es útil. "Aumentar la velocidad un 20%" no lo es.
Para profundizar en la investigación, lee Accelerate, de Forsgren, Humble y Kim. Es el libro sobre entrega de software más fundamentado en datos que conozco, y lo bastante corto para despacharlo en un fin de semana.
En Conectia, cuando integramos ingenieros senior en el equipo de un cliente, una de las primeras cosas que revisamos juntos es cómo mide el equipo su propio rendimiento. Los ingenieros que entienden las métricas DORA no se limitan a escribir código: mejoran el sistema que entrega ese código. Esa mentalidad es la que separa a un desarrollador que ocupa una silla de uno que eleva la capacidad de todo el equipo.
¿Buscas ingenieros que se preocupen por el rendimiento de la entrega y no solo por las líneas de código? Habla con un CTO — nuestros ingenieros senior de LATAM aportan las prácticas y la mentalidad que mueven tus métricas DORA en la dirección correcta.
