La estimación es uno de los temas más debatidos en las comunidades Agile. Los debates suelen ir así: story points versus horas, dimensionamiento relativo versus absoluto, #NoEstimates versus alguna estimación, planning poker versus lo que vino después.
Estos son debates reales. Y tienden a pasar por alto el problema más profundo — que los argumentos sobre cómo estimar están sustituyendo a una conversación sobre si el modelo de estimación en sí es el problema.
Lo que Agile realmente dijo sobre la estimación
Agile no surgió para ayudar a los equipos a estimar mejor. Surgió porque alguien notó que en trabajo complejo — trabajo donde los requisitos completos no pueden conocerse de antemano, donde el enfoque correcto se revela a través de la práctica — la precisión que promete la estimación es falsa precisión.
Qué significa realmente “trabajo complejo”
Esa frase — trabajo complejo, trabajo donde los requisitos completos no pueden conocerse de antemano — es fácil de pasar por alto. No debería serlo. Es la afirmación más estructural de este artículo, y sin internalizarla, todo lo que sigue puede escucharse como un argumento sobre técnicas de estimación en lugar de sobre la idoneidad de la estimación para el propósito.
El trabajo complejo no es una descripción de proyectos donde el equipo no era lo suficientemente inteligente, o riguroso, o donde aún no se había aplicado la metodología correcta. Nombra una categoría específica: trabajo donde la relación entre causa y efecto solo puede entenderse en retrospectiva. Donde el enfoque correcto se revela a través de la práctica, no del análisis. Donde los requisitos cambian no porque las partes interesadas no pensaron cuidadosamente de antemano, sino porque hacer el trabajo cambia lo que se necesita.
Las metodologías — incluso las excelentes — están construidas para trabajo simple y complicado. Operan aplicando patrones conocidos a tipos de problemas conocidos. Ese es precisamente su valor en los contextos para los que fueron diseñadas. El trabajo complejo no tiene patrones conocidos. Tiene patrones emergentes. Aplicar una metodología al trabajo complejo no resuelve el problema — crea la ilusión de estructura mientras la incertidumbre real permanece intacta. Las mini-cascadas — la planificación secuencial de ciclo corto en la que muchas implementaciones Agile se convirtieron silenciosamente — caen en la misma categoría. La duración de la iteración cambia; el supuesto subyacente de que la planificación anticipada puede guiar de manera confiable el trabajo no lo hace.
“La simplificación implacable” es una prescripción relacionada que vale la pena examinar. Si el trabajo genuinamente puede simplificarse a un tipo de problema conocido, simplificarlo — es una buena práctica. Pero es higiene, no gestión de trabajo complejo. Lo que queda después de toda simplificación posible es la parte que la resiste, que es el trabajo complejo en sí mismo, requiriendo algo que las estrategias de simplificación no están diseñadas para proporcionar. En 2025, si la respuesta competitiva a la complejidad es “deberíamos simplificar más”, la conversación sobre la gestión real del trabajo complejo aún no ha comenzado.
La reversión pública de Jeffries no es solo un cambio de opinión sobre una unidad de medición. Es el reconocimiento de algo más profundo: la premisa era incorrecta. La estimación asume una categoría de trabajo donde el análisis anticipado produce pronósticos confiables. Para trabajo simple y complicado, ese supuesto se sostiene razonablemente bien. Para trabajo complejo, no se sostiene — y ningún refinamiento de la técnica lo hará. Esa comprensión, una vez internalizada, cambia de qué trata el resto de este artículo.
Un sprint de dos semanas que entrega software funcionando no es un mejor método de estimación. Es un reemplazo de la estimación con medición empírica. En lugar de predecir cuánto tiempo tomará el trabajo, mide cuánto se hace realmente, bajo condiciones reales, en incrementos reales. La predicción es reemplazada por una cadencia y un ciclo de retroalimentación.
Esta no es una distinción sutil. Significa que los equipos que ejecutan procesos Agile pero aún tratan la estimación precisa de story points como el objetivo han malentendido fundamentalmente para qué es el proceso.
Por qué persisten los argumentos
El debate sobre la estimación persiste en parte porque las organizaciones que adoptaron Agile no renunciaron a su necesidad subyacente: sistemas de gestión construidos sobre pronósticos, presupuestos, plazos, contratos. Las ceremonias Agile se superpusieron sobre esa necesidad. Los story points se convirtieron en un sustituto de las horas. Velocity se convirtió en un insumo de planificación. Se adoptó el vocabulario Agile; la expectativa de pronóstico no fue descartada.
La situación resultante está genuinamente en disputa. Algunos equipos operan en entornos donde “sin estimaciones” es genuinamente posible — donde las partes interesadas han aprendido a confiar en la entrega empírica y no necesitan pronósticos. Otros equipos operan en entornos donde los contratos, los requisitos regulatorios o la cultura organizacional hacen que alguna forma de previsión sea inevitable.
La posición Agile no es que la estimación siempre está equivocada. Es que la estimación en trabajo complejo es estructuralmente poco confiable — que la confianza adjunta a las estimaciones supera regularmente la evidencia para ellas — y que la disciplina de ciclos de entrega cortos con retroalimentación real hace más para mejorar la previsibilidad que los mejores métodos de estimación.
El problema de las unidades — y un patrón que vale la pena notar
Una tendencia actual en los círculos Agile es alejarse de los story points hacia los Días Ideales (IPDs) — un retorno a la estimación basada en tiempo que sus defensores argumentan que es más intuitiva y más fácil de defender ante las partes interesadas.
Vale la pena saber de dónde vienen los story points. Ron Jeffries — uno de los tres fundadores de Extreme Programming y firmante original del Manifiesto Agile — inventó los story points. Surgieron directamente de los días ideales, la unidad basada en tiempo que los equipos XP usaban originalmente. El problema con los días ideales era que las partes interesadas escuchaban “tres días ideales” e interpretaban eso como un compromiso de tres días, independientemente del calificador “ideal”. Entonces la etiqueta de tiempo fue eliminada, y el número sin procesar se convirtió en la unidad. Los story points eran, en origen, días ideales con la referencia temporal eliminada específicamente para evitar que fueran tratados como compromisos de tiempo.
Jeffries ha escrito sobre esto directamente desde entonces. “Me gusta decir que pude haber inventado los story points”, escribió en 2019, “y si lo hice, lo lamento ahora.” Ahora está entre los defensores más prominentes de #NoEstimates — la posición de que el problema no es qué unidad de estimación usa, sino que la estimación en trabajo complejo es fundamentalmente poco confiable independientemente de la unidad.
Vale la pena preguntarse por qué el movimiento hacia los IPDs está ocurriendo ahora. La respuesta no es que los equipos hayan encontrado un mejor método de estimación. Es que los IPDs se alinean con la infraestructura financiera de Waterfall — los ciclos presupuestarios, los sistemas de contabilidad de proyectos, los modelos de facturación de contratos y las herramientas de planificación de personal que las organizaciones construyeron en torno a la planificación basada en tiempo y nunca cambiaron cuando adoptaron Agile. Los story points no encajan en esos sistemas. Los IPDs sí.
Esto no es una evolución de Agile. Es Waterfall continuando reafirmándose con la ropa de Agile — usando las estructuras financieras que nunca fueron desmanteladas para atraer la práctica de vuelta hacia el modelo para el que esas estructuras fueron construidas. La unidad de estimación cambió; el sistema organizacional que exige compromisos basados en tiempo no lo hizo. El resultado es el mismo teatro de pronóstico, solo con un nuevo nombre.
Esto no son empresas finalmente tomando el control y corrigiendo lo que Agile pasó por alto. Son empresas reafirmando la infraestructura que nunca cambió. Los IPDs no requieren ningún cambio en la mente, comprensión o pensamiento — simplemente se vuelven a etiquetar lo que ya se sabe. Eso es precisamente por qué están ganando terreno.
La comunidad Agile perdió aquí una oportunidad de liderazgo. Cuando la demanda de pronósticos basados en tiempo regresó disfrazada de IPDs, la respuesta correcta era nombrar lo que estaba sucediendo: esta es la financiación Waterfall reafirmándose sobre la práctica Agile. En cambio, muchos profesionales la acomodaron, tratando la demanda como una restricción a gestionar en lugar de un error de categoría a corregir. El resultado es que los equipos más fluidos en vocabulario Agile a menudo están ejecutando la versión más sofisticada del modelo que Agile fue diseñado para reemplazar.
La humanidad aprende despacio
Hay un patrón aquí que va más profundo que la metodología de estimación. Es el patrón de tratar un cambio de etiqueta como un cambio de práctica — de confundir la adopción de nuevo vocabulario con el cambio de pensamiento que ese vocabulario se suponía que debía representar.
La definición de locura de Einstein se cita frecuentemente, generalmente mal atribuida, pero siempre resonante: hacer lo mismo una y otra vez y esperar resultados diferentes. La atribución es probablemente apócrifa. El patrón no lo es. Las organizaciones que adoptaron ceremonias Agile sin adoptar el pensamiento Agile ahora están adoptando las ceremonias de reemplazo de Agile sin examinar si el pensamiento subyacente ha cambiado. Las palabras son diferentes. El modelo es el mismo.
La conversación que este artículo intenta abrir no es sobre unidades de estimación. Es sobre si su organización ha considerado genuinamente qué es el trabajo complejo y qué requiere. Si la respuesta es que su infraestructura de planificación no ha cambiado — que aún necesita pronósticos, compromisos y contabilidad basada en tiempo que asumen que el análisis anticipado produce predicciones confiables — entonces el debate sobre la estimación es un síntoma. La condición que señala es que el cambio que Agile estaba proponiendo aún no ha ocurrido.
Comentarios 0