Las estimaciones de 5 días ya no existen
Cuando una feature toma horas en lugar de semanas, el aparato de 'story points / sprint commitment' se desmorona. Tu Scrum master no sabe qué hacer.
“Esto es 5 puntos.” — frase que en 2022 significaba algo. En 2026 significa una de tres cosas:
- La feature se va a terminar en 4 horas y vas a inventar trabajo para llenar la “estimación”
- La feature va a tomar 3 semanas porque tiene complejidad oculta que tus story points no captan
- Nadie sabe qué significa “5 puntos” en este equipo, lo dijiste porque tocaba decir un número
La estimación tradicional —story points, t-shirt sizes, ideal days— se diseñó para un mundo donde escribir código era el costo dominante. Ya no lo es. Y el aparato está roto sin que muchos managers lo hayan notado.
Por qué se rompió
Tres causas que se acumulan:
1. La varianza dentro de un mismo punto. Antes, una feature “de 5” era 4-7 días con alta confianza. Hoy puede ser 4 horas (si el agente la resuelve limpio) o 3 semanas (si tiene complejidad de dominio que el agente no captura). La distribución se volvió bimodal — y los promedios mienten.
2. La complejidad ya no es proporcional al código. Antes, más código = más esfuerzo = más puntos. Hoy, una feature de 1000 líneas puede ser trivial (el agente genera) y una de 50 líneas puede ser brutal (decisión arquitectónica con 6 stakeholders). La métrica perdió correlación con la realidad.
3. La incertidumbre se movió de “implementación” a “spec”. Lo que era difícil saber antes era “¿cuánto tarda escribirlo?”. Hoy lo difícil es “¿qué exactamente vamos a escribir?”. El bottleneck es alineación, no ejecución.
Lo que vemos en equipos productivos
Los equipos que prosperan en 2026 ya abandonaron estimaciones tradicionales. En su lugar:
Buckets binarios. Una feature es “chica” (menos de 1 día, arrancamos hoy) o “grande” (más de 1 día, necesita planning explícito). Punto. La granularidad fina perdió valor.
Spec-first, no estimate-first. En lugar de estimar feature sin claridad, gastas una hora con stakeholders aterrizando spec clara. Una vez clara, la implementación es rápida — no necesitas estimar.
Tracking de cycle time real, no de estimaciones cumplidas. Métrica nueva: “¿en cuántos días promedio una decisión clara se vuelve PR mergeado?”. Esa métrica es accionable. “Cumplimos el sprint” ya no lo es.
Demos diarias, no sprint reviews. El sprint era el horizonte de planning. En 2026 el horizonte se acortó a días. Lo que estés diseñando se demuestra al stakeholder en 48 horas, no en 2 semanas.
El Scrum master en transición
Hay un rol que se ve directamente afectado: Scrum master que optimiza para velocity y burndown charts.
Esas métricas asumen que la unidad de trabajo es predecible. Ya no lo es. Velocity de un mes no predice velocity del siguiente. Burndown se cae a las 11 AM del lunes porque el agente terminó en 3 horas lo planeado para 3 días.
El Scrum master que sobrevive en 2026 pivota a:
- Facilitador de spec clarity — el bottleneck real
- Mediador entre stakeholders — el handoff es el costo nuevo
- Coach de adopción de AI — no de adherencia al framework
El que no pivota se queda midiendo lo que ya no importa.
La conversación que no estás teniendo
Si tu próximo sprint planning empieza con “este ticket es 8 puntos”, la pregunta correcta no es “¿estás seguro que es 8?”. Es “¿la spec está clara?”.
Si la spec está clara, la implementación es rápida — no necesitas estimar. Si la spec NO está clara, ningún número arregla eso.
El sprint planning ideal en 2026 no es decidir puntos. Es decidir qué de lo que está en backlog tiene la claridad suficiente para empezar mañana.
La métrica honesta
Para tu próximo sprint, ignora velocity. Mide esto:
¿Cuántas features que entraron al sprint tenían spec clara desde el lunes?
Si la respuesta es “casi ninguna, las clarificamos en el camino”, ese es tu bottleneck. No tus story points.
Si tu equipo está experimentando esta fricción y quieren rediseñar el proceso de planning para AI era, conversemos — el chat está abierto.