Pronóstico de Tasa de Llegada al Backlog

Es curioso — casi todos los equipos ágiles que conozco miden religiosamente su throughput. Cuántas historias completamos este sprint, cuántos puntos entregamos. Pero pregúntales cuántas historias nuevas llegaron al backlog y se te quedan mirando. Y esa es exactamente la métrica que te dice si tu backlog va a explotar en tres meses o se va a estabilizar. Daniel Vacanti la llama la 'métrica hermana del throughput', y tiene razón. Si llegan más cosas de las que terminas, tu backlog crece. Si crece, los tiempos de espera aumentan. Si los tiempos de espera aumentan, la previsibilidad se va al carajo. Es una cadena que empieza por no medir la entrada. Este forecaster usa dos técnicas: tendencia lineal para ver si la demanda sube, baja o se mantiene, y descomposición estacional para pillar esos patrones cíclicos que se repiten — el pico de enero, el valle de agosto, ese tipo de cosas. Con ambas juntas, tienes un pronóstico bastante decente de lo que viene.

No te voy a soltar una clase de estadística, pero sí necesitas entender lo básico para interpretar los resultados. La tendencia se calcula con una regresión lineal — básicamente, una línea recta que mejor se ajusta a tus datos. Si la línea sube, la demanda crece. Si baja, decrece. Si es plana, estable. Fácil. Lo interesante es la descomposición estacional. El modelo separa cada dato en tres partes: la tendencia general, el componente estacional (¿este mes siempre es alto o bajo?) y el residuo — la parte que no se puede explicar. El factor estacional que sale te dice cuánto se desvía cada período de lo normal. Un factor de 1.2 significa 20% más demanda. Uno de 0.8 significa 20% menos. Ahora, las métricas de precisión. El MAE te lo pone fácil: si tu pronóstico es de 50 elementos y el MAE es 4, espera algo entré 46 y 54. El R² es más abstracto — un 0.85 significa que el modelo explica el 85% de la variación en tus datos. ¿Por debajo de 0.6? Ojo, el modelo no está pillando bien tu dinámica.

¿Para qué sirve todo esto en la práctica? Para tres cosas fundamentales. Primera: planificación de capacidad. Si sabes que te van a llegar 60 elementos al mes y tu equipo completa 45, tienes un déficit de 15 por mes. En tres meses son 45 elementos acumulados en el backlog. Eso no se resuelve solo — necesitas más gente, menos alcance, o una combinación. Segunda: justificar contrataciones. Ir a tu jefe con un 'necesitamos más gente' no funciona. Ir con un gráfico que muestra una tendencia creciente de 2 elementos semanales adicionales, un pronóstico de desbordamiento en Q3, y un cálculo de cuántas personas necesitas para estabilizar el sistema — eso sí funciona. Lo he visto abrir presupuestos que llevaban meses cerrados. Y tercera: gestionar expectativas. Cuando tu product owner te pide meter 20 features en el próximo trimestre pero el pronóstico dice que van a llegar 30 bugs además, puedes tener esa conversación con datos en vez de con opiniones. Los stakeholders respetan los números — o al menos les cuesta más ignorarlos.

Tu pronóstico es tan bueno como tus datos. Punto. Si metes basura, sale basura. La primera regla es la consistencia: usa datos del mismo sistema siempre. Si un mes cuentas historias de usuario y al siguiente cuentas tareas técnicas, has roto el modelo. Otro error clásico: cambiar la definición de 'elemento' a mitad de camino. Si antes cada feature era una historia y ahora la dividís en tres, vas a ver un pico artificial que no es demanda real — es inflación. Mínimo 6 períodos para algo útil, 12 para estacionalidad. Pero ojo — revisa siempre el MAE y el R² antes de tomar decisiones. Un R² bajo te está diciendo 'no confíes mucho en esto'. Actualiza el modelo cada mes incorporando datos frescos — un pronóstico de hace tres meses ya no refleja la realidad. Y un truco que me ha salvado varias veces: cruza la tasa de llegada pronosticada con tu throughput real. Si la llegada pronosticada supera al throughput durante tres períodos seguidos, tienes un problema que no se va a resolver solo. Ese es el momento de actuar.