Nos pasa, a todos, no tengás vergüenza.

Con IA y sin. Alguien en algún momento empieza a preguntar: "¿Cuándo esta? ¿Cuándo terminamos?

Decimos: "En 3 semanas más". Llega la fecha, aun no terminamos. Surge la pregunta de nuevo. Surge la respuesta "2 semanas más." y ahí se repite el ciclo hasta ser un meme ("no de nuevo decía") con total pérdida de credibilidad.

No es que estimes mal. La estimación es una ilusión.

Nadie puede decir cuánto tardará en algo que no entiende completamente, en un contexto que cambia constantemente, con un equipo cuya capacidad varía semana a semana.

¿Entonces?

Deja de estimar. Empezá a medir

El Sistema

Tres pasos:

1. Divide característica/historia en tareas pequeñas

• Cada tarea ≤ 1 día ideal
• Si parece más grande de un día la dividís.
• Si sigue siendo grande, dividís de nuevo
• Resultado: tareas comparables y además un plan ejecutable y refinado.

2. Registra cada semana

• Cuántas tareas completó cada dev.

• Semana 1: 4 tareas

• Semana 2: 7 tareas

• Semana 3: 6 tareas

• ...

• Semana 8: converges

3. Predecí con actualización Bayesiana

• Después de 8 semanas: sabes distribución real de cada desarrollador.
• Backlog actual tiene X tareas
• Simula 10k escenarios con esas distribuciones.
• Resultado: "con 95% de confianza, no terminamos antes del día Y"

No es complicado.

Por qué funciona

Las distribuciones convergen a capacidad real no importa si la tarea tomo más de un día siempre que hayamos intentado que tomara a lo sumo un día. Recordá que dije 'un día ideal', seamos honestos la mayoría de los días están lejos de ser ideales. Pero la ley de los grandes números está a nuestro favor, finalmente la capacidad real converge.

No es esperás 8 semanas para "entrenar" el modelo.

Semana 1-3:

• Dev A hace 20 tareas (contexto simple)
• Dev B hace 5 tareas (aprende)
• Variación alta

Semana 4-6:

• Complejidad aumenta (arquitectura, dependencias)
• Dev A hace 12 tareas
• Dev B hace 9 tareas
• Se estabiliza

Semana 7-8:

• Distribución converge
• Dev A: 11 ± 2 tareas
• Dev B: 10 ± 2 tareas
• Eso es su capacidad real

No necesitas "ajustar manualmente". Los datos lo hacen solitos.

Actualización Bayesiana

Lo que estás haciendo es ajustar tus creencias a la evidencia:

• Semana 1: "Asumo que el dev hace ~25 tareas" (prior)
• Dev hace 23 (observación)
• Semana 2: ajusta estimación a 24 (posterior = nuevo prior)
• Dev hace 26
• Semana 3: ajusta a 25
• ... semana 8: converge a distribución real

Cada semana mejora la predicción automáticamente.

Estás sincronizando tu modelo con la realidad semanal.

Gestión de Expectativas (Lo Importante)

*La mayoría de software estima para evitar responsabilidad. *

Sin datos:

• "Terminamos en 3 semanas" (esperanza optimista)
• Falla: "Sorpresas, dependencias, cambios de scope"

Con datos:

• Semana 1: "No tengo datos. 6/7 meses creo."
• Semana 4: "Con 70% de confianza, 24 semanas."
• Semana 8: "Con 95% de confianza, 17 semanas."
• Semana 12: "Actualizando... 9 semanas."

El PM no promete fechas optimistas. Promete rangos realistas.

El cliente sabe qué esperar. Vos sabes qué esperar. El dev sabe qué esperar.

Eso es gestión de expectativas con evidencia.

Lo que cambió

No fue solo predicción. Fue cómo trabajábamos:

1. Refinamiento forzado

• Para dividir features, necesitas pensar en pasos
• Dev no puede decir "voy a hacerla" sin plan
• Resultado: menos sorpresas, ejecución más limpia

2. Dailies claras

• "¿Dónde estás?" → "Terminé la tarea X, empecé la Y para completar la feature"
• No,"estoy trabajando en la feature" (nada claro)
• Visibilidad real

3. Bloqueos visibles

• Si alguien no termina tareas, se ve en los números
• ¿Es capacidad? ¿Son bloqueos externos? Los datos nos dicen
• PM interviene, cero dramas, son datos

4. Devs caóticos se exponen y aprenden

• Algunos devs , le cuesta dividir en tareas.
• La distribución reflejaba eso (muy variable, baja velocidad)
• Con insistencia, mejoraron o mostraban su verdadero desempeño
• No fue culpa, fue realidad

Las Limitaciones

No hace por nosotros, ni el producto correcto, ni evitar retrasos o cambios.

1. Tarda 8 semanas

• Si son caóticos, tarda en converger.
• Necesitas ~8 semanas reales (56 días)
• Después la precisión mejora y mejora

2. Requiere equipo estable

• Si rotan gente cada 2 semanas, la distribución se rompe, podemos usar una priora informada, pero ya es más complicado.
• Cambio de contexto grande, producen redistribuciones
• Pero se ajusta automáticamente cada semana, si la historia es muy pesada podemos usar ventanas deslizables sobre los datos para reducir el peso de la evidencia histórica a cambio de mayor varianza

3. Depende de división clara

• Si dividís mal (tareas poco claras), los datos son ruido
• Pero el sistema lo expone: tareas que dicen ser "pequeñas" pero no terminan.

4. Backlog en movimiento

• Si el MVP crece 50% en la semana 5, la predicción se recalcula
• Eso es correcto, no fallo del sistema.

5. Bloqueos externos

• Si hay 2 semanas de bloqueo por infra/aprobaciones
• Velocidad baja esas semanas
• Se refleja en los números (correctamente)

¿Si es tan bueno porque no lo hace nadie?

El software aplica técnicas sofisticadas para todo... menos para sí mismo.

• *Meteorología: * Recalcular predicciones cada hora.
• *Logística: * ETAs que se ajustan con datos.
• *Control de Calidad/Industrial: * Medir capacidad real.

Como casi todo, es multi causal. Te digo algunas:

1. Waterfall dejó cicatrices perpetuas

   • "Medir y registrar" suena a viejo, rígido
   • "Agile" mal entendido.

2. Presión política

   • Datos reales exponen problemas: "¿Por qué tan lentos?"
   • Estimar es cómodo: Luego decir "pasaron cosas" para justificarse.

3. Ilusión de control

   • Un PM prefiere oír "2 semanas" (certeza falsa)
   • Que "70% de confianza, 2-4 semanas" (realidad incómoda)
   • El número da "certeza". La distribución da "responsabilidad".

4. Herramientas

   • Jira está diseñada para estimaciones (story points)
   • Medir requiere disciplina

¿Cómo Implementarlo?

Semana 1:

• Agarrar el MVP
• Tomar las features y dividirlas en tareas de un día.
• Contás tareas, digamos 120 tareas para el MVP

Semanas 2-8:

• Cada semana: registrás tareas completadas
• Cada semana: recalculás predicción

Semana 9+:

• Predicción confiable
• Recalcula cada semana (automático)
• Usa para decisiones de prioridad, scope, comunicación con stakeholders

Código (Pseudo)

Si quieres hacer la simulación:

import numpy as np

# Datos históricos (semanas 1-8)
dev_a_velocidad = [20, 22, 19, 21, 20, 23, 21, 22]  # tareas/semana
dev_b_velocidad = [15, 14, 16, 15, 17, 15, 16, 15]

# Parámetros distribuciones, asumiendo normalidad
velocidad_a = np.mean(dev_a_velocidad)  # ~21
std_a = np.std(dev_a_velocidad)         # ~1.2
velocidad_b = np.mean(dev_b_velocidad)  # ~15.4
std_b = np.std(dev_b_velocidad)         # ~0.8

backlog_tareas = 200  # tareas restantes

# Simulación Monte Carlo
simulaciones = 10000
dias_para_terminar = []

for _ in range(simulaciones):
    # para simplificar el ejemplo usamos una distribución normal
    tareas_semana_a = np.random.normal(velocidad_a, std_a)
    tareas_semana_b = np.random.normal(velocidad_b, std_b)
    tareas_por_semana = tareas_semana_a + tareas_semana_b

    semanas_necesarias = backlog_tareas / tareas_por_semana
    dias = semanas_necesarias * 7
    dias_para_terminar.append(dias)

# Resultado
percentil_95 = np.percentile(dias_para_terminar, 95)
percentil_50 = np.percentile(dias_para_terminar, 50)

print(f"Mediana: {percentil_50:.0f} días")
print(f"95% confianza (worst case): {percentil_95:.0f} días")

Eso es. 20 líneas. Nada de magia.

¿Como se ve?

Estas distribuciones son las que convergen.

Así se ven las distribuciones. Ajustadas, notá que no asumo normalidad. Mi versión productiva ajusta distribuciones antes del MC.

Vemos el efecto de las tres distribuciones en las fechas de entrega. (100k simulaciones)

Lo que no estoy diciendo que es!!!

• "Esto es perfecto": No !!
• "Todos deberían hacerlo": Para nada.
• "Reemplaza a los devs estimando": Dividir en tareas es estimar.
• "Es Waterfall disfrazado": Nop.
• "Pero no puedo divi ...": Lo importante es dividir el elefante en pedacitos masticables. La idea es contar 'melones', onzas o kilos no te importan, a larga en el carro se acomodan.
• "Story Points": Si, podes aproximar la distribución o usar tus datos históricos como bootstrap para el Montecarlo.

Esto no es nada nuevo

Esto no es innovación, ni hype. Es ingeniería clásica.

En construcción, medicina, logística, manufactura, Miden. No estiman. y lo que estiman es a sus clientes por eso miden.

Que software sea la excepción, no significa que la excepción sea correcta.

Probalo.

Si no te gusta no hay problema solo contame ...

¿Estimas o medis?

¿Tus predicciones aciertan?

¿Usas algo similar?