En un artículo anterior, fuimos bastante claros (y quizás un poco polémicos) al recomendarte que dejes de usar Story Points y la Velocity. Sabemos que para muchos Scrum Masters y equipos ágiles, esto suena a herejía. «¿Cómo vamos a saber cuándo terminaremos si no estimamos?», «¿Cómo planificamos el Sprint sin saber cuántos puntos caben?».
El miedo al vacío es real. Si le quitas a un equipo su muleta de «Puntos de Historia», se sienten desnudos ante la incertidumbre. Pero la realidad es que los Story Points son estimaciones subjetivas de esfuerzo, no datos reales de entrega. Y basar tu negocio en suposiciones de esfuerzo suele llevar a la frustración.
Entonces, si eliminamos la bola de cristal de la estimación, ¿qué nos queda? Nos quedan los datos. Nos queda la evidencia histórica. Nos quedan las Métricas de Flujo.
Hoy vamos a ver qué debe medir realmente un Scrum Master profesional para ayudar a su equipo a ser predecible sin necesidad de jugar al póker.
El cambio de mentalidad: Del Esfuerzo al Flujo
El error fundamental de la gestión tradicional (y del Scrum mal entendido) es obsesionarse con la utilización de recursos (que todos estén ocupados al 100%) y la estimación del esfuerzo (cuánto nos va a costar).
Las métricas de flujo cambian el foco hacia la entrega de valor. No nos importa si Juan estuvo 8 horas tecleando; nos importa cuánto tiempo tardó un ítem en pasar de «To Do» a «Done». Al centrarnos en el flujo, dejamos de gestionar personas y empezamos a gestionar el trabajo.
Para esto, necesitamos cuatro métricas clave que todo Scrum Master debería tener en su dashboard (y ninguna de ellas requiere estimar).
1. Throughput (Tasa de Entrega)
Olvídate de la «Velocidad» en puntos. El Throughput es simplemente el número de ítems de trabajo (PBIs, historias de usuario, bugs) que el equipo termina en un periodo de tiempo determinado (por ejemplo, por día o por Sprint).
- ¿Por qué es mejor que la Velocity? Porque es un dato real, no una suposición. «En el último Sprint terminamos 12 ítems». No hay debate.
- ¿Pero no son todos los ítems de distinto tamaño? Sí, y no importa. La ley de los grandes números nos dice que, a lo largo del tiempo, el tamaño promedio de los ítems tiende a estabilizarse. Si tus ítems son lo suficientemente pequeños para entrar en un Sprint, contar cuántos terminas es estadísticamente más fiable para predecir el futuro que sumar puntos abstractos.
2. Cycle Time (Tiempo de Ciclo)
Esta es la métrica reina desde la perspectiva del cliente. El Cycle Time mide el tiempo transcurrido desde que el equipo empieza a trabajar en un ítem (pasa a «In Progress») hasta que está terminado (llega a «Done»).
Un Scrum Master efectivo no pregunta «¿cuánto te falta?», sino que observa el Tiempo de Ciclo promedio del equipo.
- El objetivo: Reducir el Cycle Time. Cuanto menor sea, más rápido recibe valor el cliente y más rápido obtenemos feedback.
- La herramienta: El Scatter Plot (Gráfico de Dispersión). Visualiza cada tarea terminada como un punto en un gráfico. Esto te permite decir: «Históricamente, el 85% de nuestros ítems se terminan en 6 días o menos». Eso es una SLE (Service Level Expectation), y es mucho más potente que decir «creo que es un 5».
3. Work Item Age (Edad del Ítem de Trabajo)
Si el Cycle Time es una métrica «lagging» (nos dice lo que ya pasó), el Work Item Age es una métrica «leading» (nos dice lo que está pasando ahora y nos permite actuar).
Esta es la métrica más importante para tu Daily Scrum. Mide cuánto tiempo ha pasado desde que un ítem activo comenzó.
- El problema: Si tu SLE dice que el 85% de las tareas se acaban en 6 días, y tienes una tarea en el tablero que lleva 8 días «en progreso», tienes un problema. Esa tarea se está convirtiendo en un «outlier» (una anomalía).
- La acción del SM: Tu trabajo es visibilizar esto. Ese ítem está «envejeciendo» mal. Cuanto más envejece un ítem, menor es la probabilidad de que se termine pronto.
4. WIP (Work In Progress)
El WIP es la cantidad de trabajo que ha empezado pero no se ha terminado. Es el enemigo silencioso de la productividad. La Ley de Little nos enseña que, para un sistema estable, si aumentas el WIP, aumentas el Cycle Time.
Es decir, cuantas más cosas intentéis hacer a la vez, más tardaréis en entregar cada una de ellas. Un Scrum Master debe monitorizar el WIP y ayudar al equipo a limitarlo para mejorar el flujo.
Cómo transformar tu Daily Scrum con estas métricas
Aquí es donde la teoría se encuentra con la práctica. La mayoría de los Daily Scrums son aburridos reportes de estado: «Ayer hice esto, hoy haré esto, no tengo impedimentos».
Como Scrum Master, puedes cambiar esto radicalmente usando el Work Item Age.
En lugar de mirar a las personas, mirad el tablero. Empezad por la derecha (lo que está más cerca de terminarse) y buscad los ítems más viejos.
Preguntas poderosas basadas en flujo para la Daily:
- «Este ítem lleva 7 días en curso y nuestro promedio es 5. ¿Qué podemos hacer hoy entre todos para cerrarlo?»
- «Tenemos 10 elementos en progreso para 5 personas. ¿Estamos bloqueando el flujo? ¿Deberíamos dejar de empezar cosas nuevas y terminar las viejas?»
- «Esta historia está envejeciendo peligrosamente. ¿Quién puede dejar lo que está haciendo para ayudar a terminarla (Swarming)?»
Conclusión: Predicción Probabilística
Al recopilar estos datos (Throughput y Cycle Time), puedes dejar de usar la bola de cristal y empezar a usar Simulaciones de Monte Carlo.
En lugar de comprometerte a un alcance fijo basado en puntos inventados, podrás decirle a tus Stakeholders: «Basándonos en nuestro rendimiento real de los últimos 3 meses, tenemos un 85% de probabilidad de entregar 20 ítems o más en el próximo release».
Esto cambia la conversación. Pasas de prometer y fallar, a gestionar riesgos y probabilidades de manera profesional.
Deja los Story Points para los libros de historia. Si quieres agilidad real, empieza a gestionar el flujo.
¿Quieres profundizar?
Si este artículo te ha hecho replantearte tus métricas, quizás te interese nuestro curso de Professional Scrum, donde enseñamos a configurar y leer estas métricas en profundidad.