Cómo construir un modelo de inteligencia para medir la madurez de entrega Agile
Corrige a tiempo el error que cometen la mayoría de equipos Agile al medir su rendimiento
El problema que siempre se repite
Hay una historia que vuelve una y otra vez en casi todos los equipos Agile:
El sprint termina
El equipo celebra
Se han completado 30 puntos de historia
La velocidad es buena
La daily del lunes empieza a tope
Y, sin embargo, hay 12 tareas pendientes que se arrastran al siguiente sprint.
Hay trabajo aún comprometido que no hemos entregado.
Es un patrón que se está repitiendo desde hace tres meses pero que nadie lo quiere sacar a relucir.
La velocidad no te dice si tu equipo es predecible, ni si su planificación es realista, o si el trabajo que no termina está acumulando riesgo operativo real.
Esa es la pregunta que me hice cuando diseñé este proyecto en Power BI:
¿Qué necesita ver realmente una PMO o un Delivery Manager para saber si un equipo está entregando bien o sólo entregando rápido?
Este modelo lo he diseñado para exponer problemas, no para ocultarlos.
El escenario: tres equipos, quince sprints y tres historias distintas
Para responder esa pregunta, construí un entorno de datos con tres equipos y quince sprints de historia de entrega.
Diseñé los equipos para reflejar algo que cualquier organización pueda reconocer:
Equipo A funciona como el benchmark. Predecible, estable, con alta consistencia sprint tras sprint.
Equipo B empieza en un estado crítico y protagoniza una recuperación progresiva. Sus primeros sprints son los más problemáticos del conjunto.
Equipo C recorre un camino de transformación más lento, mejorando gradualmente pero con mayor variabilidad que los otros dos.
Son tres trayectorias distintas pero las mismas métricas aplicadas a los tres equipos.
Eso es lo que permite que el dashboard cuente una historia diferente para cada equipo y que esa historia sea útil para tomar decisiones con datos.
La decisión de diseño que lo cambia todo
Cuando empecé a estructurar el dashboard, tuve que responder la pregunta clave:
¿Qué significa que un sprint sea saludable?
La respuesta obvia es que se completó el trabajo comprometido, pero eso no es siempre suficiente.
Un equipo puede completar el 90% de sus puntos de historia y aun así tener aún trabajo pendiente sin cerrar.
Eso es una foto parcial con riesgo real.
Por eso diseñé un Sprint Health Score que combina dos dimensiones simultáneamente:
Predictibilidad: ¿cuánto del trabajo comprometido se entregó realmente?
Trabajo pendiente: ¿cuánto quedó sin terminar al cierre del sprint?
Un sprint sólo es saludable si ambas dimensiones están controladas, con una no basta.
El resultado es un modelo con tres niveles {Healthy, Warning, Critical} con umbrales definidos de forma deliberadamente exigente: para que el indicador sea honesto, no para penalizar a los equipos.
Lo que dicen los datos
Con ese modelo aplicado a los quince sprints, los resultados fueron claros y a primera vista, sorprendentes.
Solo el 33% de los sprints se clasificaron como saludables. Cuatro sprints alcanzaron estado crítico. El health score promedio del conjunto fue 2,2 sobre 3.
¿Es eso malo? Depende de qué esperes encontrarte.
Si esperas que un dashboard valide que todo va bien y en colorcitos verdes, sí.
Si esperas que un dashboard te diga dónde está el riesgo real en tu proyecto, entonces el 33% es exactamente la respuesta correcta porque refleja la realidad de equipos en distintos momentos de madurez, no una foto retocada.
Lo que sí es una señal positiva: la evolución de los 3 equipos ágiles.
El Sprint Health Score mejora consistentemente desde el sprint 1 hasta el sprint 15 en todos los equipos. La predictibilidad global cierra en un 88%. El gap de entrega (la diferencia entre lo comprometido y lo completado) se mantiene en un 11,9%, con tendencia decreciente.
Tres páginas, una conversación ejecutiva
El dashboard tiene tres vistas, y cada una responde una pregunta diferente:
¿Están mis equipos entregando con salud?
La primera página, Agile Delivery Health, muestra el Sprint Health Score por equipo y su evolución en el tiempo. En una sola pantalla puedes ver qué equipos tienen sprints críticos, cómo ha evolucionado su salud y comparar los tres equipos entre sí.
¿Son mis equipos predecibles y estables?
La segunda página, Predictability vs Stability, posiciona a cada equipo en un mapa de madurez de entrega. El eje horizontal mide la estabilidad de la velocidad. El eje vertical mide la predictibilidad media. En un vistazo, sabes quién es el benchmark y quién está en proceso de recuperación.
¿Cómo evoluciona el rendimiento sprint a sprint?
La tercera página, Sprint Delivery Performance, muestra la tendencia de velocidad y predictibilidad a lo largo de los quince sprints, junto con el committed vs completed. Es la vista que une el qué con el cuándo.
Lo que aprendí construyendo este informe
Tres aprendizajes que me parecen más útiles que cualquier métrica del dashboard:
1. El diseño del problema es más difícil que el diseño del dato.
Antes de escribir una sola línea de código o una sola fórmula, tuve que decidir qué significaba "salud de entrega". Esa decisión de negocio es la que da valor al modelo. Sin ella, es sólo un conjunto de gráficos con números sin sentido.
2. Los datos bien diseñados cuentan historias reales.
Este dataset no viene de un proyecto real (no puedo proporcionarlo) pero todos los datos del proyecto reflejan patrones que he visto en la vida real. La diferencia entre datos de ejemplo y datos de demostración es que tienen una narrativa detrás.
3. El 33% de sprints saludables es pura honestidad.
Uno de los mayores riesgos en los dashboards de Agile es que los indicadores se calibran para dar buenas noticias. Este modelo hace lo contrario: es deliberadamente exigente porque la exigencia es lo que hace útil a un indicador de riesgo.
Para quien quiera ir más lejos
Si te interesa el detalle técnico del archivo Power BI (en inglés): las medidas DAX, la lógica detrás de los cálculos , los objetos visuales, lo tienes todo documentado en mi repositorio de GitHub, incluyendo el archivo .pbix para descargar y explorar.
Comentarios