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 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. 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. 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. *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. 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 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) 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: Waterfall dejó cicatrices perpetuas "Medir y registrar" suena a viejo, rígido "Agile" mal entendido. Presión política Datos reales exponen problemas: "¿Por qué tan lentos?" Estimar es cómodo: Luego decir "pasaron cosas" para justificarse. 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". Herramientas Jira está diseñada para estimaciones (story points) Medir requiere disciplina 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 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. 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) "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 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. ¿Estimas o medis? ¿Tus predicciones aciertan? ¿Usas algo similar?