Por qué falla la estimación (y por qué sigue siendo necesaria)

• En el desarrollo de software, la estimación del trabajo pertenece al dominio complejo (Complex), y ni siquiera un equipo muy experimentado puede estimar con precisión de forma inherente
• El movimiento #NoEstimates fue una reacción legítima frente a la realidad de que las estimaciones se usan indebidamente como objetivos de desempeño, pero rechazar la estimación en sí hace que la organización pierda su capacidad de coordinación
• El valor central de la estimación no es predecir el futuro, sino comunicar y coordinar bajo incertidumbre, y es indispensable para contratos externos, dependencias entre equipos y decisiones de ROI
• Según el Cone of Uncertainty de Steve McConnell, al inicio de un proyecto el error de estimación puede llegar a ser de 4x, y solo se reduce mediante aprendizaje
• Hay que cambiar el hábito organizacional de convertir estimaciones en compromisos y adoptar una forma de estimar basada en rangos, con supuestos explícitos y ajustes graduales

---

El problema que realmente resolvió el movimiento #NoEstimates

• Se repite un patrón en el que se le pide una estimación al equipo cuando todavía sabe muy poco del problema, ese número se incorpora al roadmap y termina prometiéndose al cliente
• Cuando la realidad se desvía de la estimación, se culpa al equipo por "no cumplir la fecha límite", aunque en realidad nunca fue una fecha acordada por ellos
• La patología central es que la estimación deja de ser una predicción y se degrada en un compromiso (commitment)
• La solución de "no estimemos" se parece a negar el concepto mismo de temperatura como reacción a un termómetro descompuesto
• Como lo expresa Maarten Dalmijn, estimar no cambia la cantidad real de trabajo; desarrollar una funcionalidad toma lo que toma
  • Lo que la estimación afecta no es el trabajo en sí, sino las expectativas (expectations) que lo rodean
  • Gestionar esas expectativas con honestidad y claridad es un trabajo que sí vale la pena

Por qué las organizaciones realmente necesitan estimaciones

• Un punto que casi siempre falta en el debate de #NoEstimates: las estimaciones no son para el equipo que ejecuta el trabajo, sino para la organización que lo rodea

• Hay tres situaciones en las que la estimación es inevitable

• Compromisos externos (External commitments): en contratos con clientes, lanzamientos sincronizados con campañas de marketing o fechas regulatorias, hace falta un modelo del tiempo requerido para evaluar si algo es viable

  • "Nosotros no hacemos estimaciones" no es una respuesta que puedas darle a un cliente, y puede terminar en la pérdida del contrato

• Dependencias entre equipos (Inter-team dependencies): si el equipo B tiene que esperar a que el equipo A termine, y el equipo A no ofrece ninguna previsión, el equipo B no puede planear

  • Una señal aproximada ("quizá 6 semanas, máximo 8") es infinitamente más útil que el silencio, y no se trata de control sino de respeto hacia quienes están río abajo en la cadena de trabajo

• Cálculo de ROI: para decidir si conviene construir la funcionalidad X o la Y, hace falta un modelo relativo de costo

  • Si todo es incognoscible, no se pueden hacer trade-offs racionales; y si de todos modos vas a adivinar, es mejor una adivinanza estructurada con supuestos explícitos

La dificultad esencial de estimar que mostró Joseph Pelrine

• Joseph Pelrine fue el primer Certified Scrum Trainer de Europa y estudia el desarrollo ágil de software a través del lente de la ciencia de la complejidad social
• Realizó un experimento con más de 300 personas que trabajan en desarrollo ágil de software, ubicando actividades cotidianas en los dominios del framework Cynefin (modelo de sensemaking de Dave Snowden)
  • Cynefin clasifica los problemas en cuatro dominios: Clear, Complicated, Complex y Chaotic
• La estimación del trabajo se ubicó de forma consistente y repetida en el dominio Complex
• La clave está en la diferencia entre Complicated y Complex:
  • En el dominio Complicated, las relaciones causa-efecto pueden identificarse, los expertos pueden rastrearlas y el conocimiento especializado genera predicciones confiables
  • En el dominio Complex, las relaciones causa-efecto solo pueden comprenderse a posteriori, porque el sistema está demasiado entrelazado, depende demasiado del contexto y es sensible a cambios pequeños
• Esa es la razón por la que desarrollar software no es lo mismo que manufacturar: casi siempre se construye algo que no existía antes, sobre una base de código única y con dinámicas de equipo también únicas
  • Por eso la analogía del carpintero no funciona: un gabinete se parece más o menos a otro gabinete, pero una funcionalidad no se parece más o menos a otra funcionalidad
• Incluso los mejores equipos solo pueden lograr estimaciones de nivel promedio, no por falta de habilidad, sino porque hay límites inherentes a la precisión dentro del dominio Complex
• El objetivo no es atinarle a la estimación, sino tomar decisiones útiles a pesar de la inexactitud inherente

Lo que nos dice el Cone of Uncertainty

• El concepto de Cone of Uncertainty de Steve McConnell: al inicio del proyecto, el error de estimación puede llegar a 4x en ambas direcciones (un rango total de 16x)
• A medida que el proyecto avanza y se resuelven incógnitas (se aclaran requisitos, se confirma la arquitectura, se descubren y resuelven problemas difíciles), el cono se estrecha
• La ironía: el momento en que la estimación se vuelve más precisa es justo antes de terminar, que es cuando menos se necesita
  • Al inicio, cuando sería más útil (cuando todavía se puede cambiar de dirección o cancelar el proyecto), es cuando menos se sabe
  • La mayoría de las organizaciones hacen sus compromisos más firmes justamente en ese momento inicial
• Dos implicaciones adicionales:
  • El cono representa el mejor caso para estimadores expertos, y la mayoría de los equipos lo hace peor que eso
  • Fijar una fecha en la etapa conceptual inicial no es planificación, sino pedir un deseo y programar el calendario en torno a él
  • El cono no se estrecha por el paso del tiempo, sino por decisiones que eliminan incertidumbre
  • Definir el alcance, resolver incógnitas de arquitectura, escribir código real y descubrir obstáculos estrecha el cono; pasar tres semanas solo en reuniones no lo hace
• Hay que comunicar explícitamente a los stakeholders que "la calidad de una estimación depende de en qué punto del cono estamos"
  • En la semana 1 no puedes dar un número como si fuera de 2 semanas, pero sí puedes dar un rango y explicar qué hace falta confirmar para estrecharlo
  • La mayoría de los stakeholders lo acepta cuando se les explica el cono; simplemente nadie les dijo que también podían pedir rangos

Por qué se usa la escala Fibonacci

• La no linealidad de la escala Fibonacci (1, 2, 3, 5, 8, 13, 21) cumple un trabajo epistemológico
• La diferencia entre 2 y 3 solo indica una "diferencia aproximada", pero el salto de 8 a 13 codifica que la banda de incertidumbre es más amplia que el propio valor estimado
  • Una historia de 13 puntos no significa "exactamente 13", sino "claramente más incierta que 8, pero no tanto como 21"
• La separación entre números Fibonacci refleja cómo realmente escala la complejidad
  • Lo pequeño puede estimarse más o menos; lo grande es exponencialmente más difícil de predecir porque tiene más incógnitas, más puntos de integración y más imprevistos
  • Una historia de 21 (o incluso 13) puntos significa: todavía no entendemos bien el trabajo y hay que dividirlo
• Otra función subestimada de estimar con Fibonacci es lo que ocurre durante la conversación de estimación
  • Si una persona dice 3 y otra 13, el número en sí casi no importa; lo importante es por qué el mismo equipo ve la misma historia de formas tan distintas
  • Puede que una persona haya detectado una dependencia o conozca una limitación técnica que no aparece en el ticket
• El mayor valor de la estimación no está en el número, sino en verificar si se construyó un entendimiento compartido
  • Si quitas ese mecanismo forzador, muchas veces el entendimiento compartido no aparece hasta que alguien se topa con complejidad oculta en el tercer día de trabajo
• Por eso cuesta aceptar la idea de #NoEstimates de que "las reuniones de estimación son un desperdicio": si se hacen bien, ahí ocurre el alineamiento (alignment)
  • La respuesta a reuniones mal llevadas no es cancelarlas

La trampa del compromiso (Commitment Trap) y cómo evitarla

• La disfunción más profunda a la que reaccionó #NoEstimates: la estimación se convierte en compromiso por presión social, no por lógica
• Un modo de falla relacionado: cuando personas que no hacen el trabajo crean un timeline y se lo lanzan al equipo, se produce la peor combinación posible: estimaciones inexactas + un equipo sin sentido de propiedad sobre esos números
  • Cuando la realidad no coincide, nadie sabe de quién es la responsabilidad y todos terminan culpando a todos
  • Las personas que ejecutan el trabajo siempre deben ser dueñas de la estimación, e imponer estimaciones desde fuera no es optimismo sino el preludio de un juego de culpas
• Cuando se instala la obsesión con la fecha límite, toda conversación converge en "¿cómo cumplimos la fecha?", y desaparece de vista la pregunta de si estamos construyendo lo correcto
• Hay que separar tres cosas que la mayoría de las organizaciones confunde:
  1. Estimación (Estimate): una predicción probabilística dada la incertidumbre actual, que debe venir acompañada por una declaración explícita de rangos y supuestos
     • Ejemplo: "Suponiendo que no cambien los requisitos y que recibamos respuesta a las preguntas sobre la API antes del próximo viernes, lo vemos en 4 a 6 semanas"
  2. Plan (Plan): un compromiso no con el resultado, sino con el proceso
     • Ejemplo: "Trabajaremos dos semanas, revisaremos el avance y daremos una previsión actualizada"
  3. Compromiso (Commitment): una promesa sobre un resultado, que debe hacerse rara vez y con cuidado, solo cuando el cono ya se haya estrechado lo suficiente
     • Comprometerse en la etapa conceptual inicial no es valentía, sino imprudencia
     • Cuando te exijan un compromiso, intenta comprometerte no con el timeline sino con las prioridades; y si ni eso funciona, incluye el nivel de confianza como parte del compromiso
• La práctica organizacional de tratar cualquier estimación como compromiso desde el momento en que se pronuncia es la raíz de la disfunción
  • Se entiende la solución política de #NoEstimates (no dar números en absoluto), pero el costo es que la organización pierde la capacidad de asignar recursos, ordenar dependencias y tener conversaciones honestas con stakeholders externos
• La mejor salida es enseñar el cono, educar a los stakeholders y dejar explícita la diferencia entre estimación y compromiso cada vez que se da un número
  • Es más difícil y toma más tiempo que negarse a estimar, pero en vez de esquivar situaciones donde la confianza puede romperse, construye confianza

Buenas prácticas para estimar

• Estimar tarde: el cono solo se estrecha con aprendizaje, así que primero hay que hacer spikes, escribir código exploratorio y hablar con los equipos con los que habrá integración
  • Hay que resistir la presión de dar números antes de tener el aprendizaje necesario para que signifiquen algo
• No descomponer en exceso antes de empezar: frente a la incertidumbre, da ganas de dividir el trabajo en partes cada vez más pequeñas, pero eso por sí solo no produce estimaciones confiables
  • Un plan previo demasiado detallado se rigidiza y hace que el equipo se aferre a él incluso cuando ya dejó de reflejar la realidad, lo que vuelve más confuso el desfase final
  • Conviene empezar con un plan simple y fácil de ajustar
• Dar rangos, no estimaciones puntuales: "3 a 5 semanas" es más honesto que "4 semanas" y casi igual de utilizable
  • Si te exigen un solo número, da el punto medio del rango, pero aclara que es un punto medio
  • Acordar con los stakeholders el uso del Cone of Uncertainty y referenciarlo cada vez que se comunica una estimación
• Hacer visibles los supuestos: una estimación vale tanto como sus supuestos, así que hay que explicitar si se asume que no cambiará el alcance, que se usará cierto enfoque técnico o que otro equipo entregará en determinada fecha
  • Los supuestos que solo existen en la cabeza de alguien terminan emergiendo como malentendidos en el peor momento posible
• Hacer seguimiento a la precisión, pero sin castigo: el objetivo no es culpar sino calibrar
  • Un equipo que estima junto durante seis meses y revisa su precisión desarrolla una intuición compartida sobre dónde suele sobreestimar o subestimar
  • Si se castigan las estimaciones imprecisas, el equipo empezará a inflarlas de forma defensiva, y una estimación inflada es menos útil que una estimación honesta aunque incierta
  • En el dominio Complex, una mala estimación no es un defecto de carácter, sino una propiedad del dominio
• Si pasa de 8, dividir: una historia Fibonacci de 13 o 21 casi siempre contiene complejidad oculta que aún no salió a la superficie
  • El acto de dividir obliga a expresar con claridad qué se sabe realmente
  • A menudo descubres que de tres subhistorias, dos son pequeñas y una concentra toda la incertidumbre

Una verdad incómoda para ambos bandos

• Estimar no es calcular, sino una forma de comunicación; su propósito no es predecir el futuro, sino apoyar la coordinación y la toma de decisiones bajo incertidumbre
• Los modos de falla de la estimación no son aleatorios, sino sistemáticos: estimar demasiado pronto, tratar un rango como si fuera un punto, tratar la estimación como compromiso, ignorar la posición epistemológica del cone y obligar a quienes ejecutan a aceptar estimaciones impuestas
• Lo que Dalmijn llama la falacia de estimación del trabajo complejo (Complex Work Estimation Fallacy): creer que si estimamos más seguido, mejoramos el proceso y trabajamos más tiempo juntos, eventualmente obtendremos estimaciones precisas
  • En el dominio Complex, el límite de precisión de la estimación no es función de la madurez del equipo, sino del dominio mismo
  • Se puede mejorar, pero no volverse preciso; y confundir ambas cosas lleva a que la organización castigue al equipo por algo que está, en esencia, fuera de su control
• Rechazar la estimación no es más que salirse del juego de la coordinación
  • Puede funcionar para equipos completamente autónomos, con despliegue continuo y sin compromisos externos, pero la mayoría de las trayectorias profesionales no transcurre en ese contexto
• La elección real no es entre "mala estimación" y "sin estimación", sino entre estimaciones implícitas y de baja calidad (que la organización de todos modos hará sin ti) y estimaciones explícitas, humildes, basadas en rangos y con supuestos visibles
• Como la estimación del trabajo pertenece al dominio Complex, hay que abordarla con una mentalidad de complejidad: explorar, observar, responder, estimar, seguir y calibrar en ciclos repetidos
• El cono no se estrecha esperando, sino aprendiendo