El cono de incertidumbre en la estimación ágil
Las estimaciones iniciales presentan un amplio margen de variación porque se desconoce el alcance del trabajo, no porque su equipo no sea capaz de realizar estimaciones adecuadas. Qué significa el «cono de incertidumbre» y cómo reducirlo —en lugar de ampliarlo—.
Su estimación inicial es la peor de todas —y eso es una característica inherente al trabajo, no un defecto del equipo—. El «cono de incertidumbre» es la razón por la que debe dejar de exigir una cifra concreta para algo que aún no se ha empezado a hacer.
El cono es una observación sencilla con consecuencias muy claras: al inicio de un proyecto, la diferencia entre su estimación y la realidad es enorme, y se va reduciendo a medida que va adquiriendo conocimientos. Barry Boehm detectó esta forma en los datos sobre los costes del software; Steve McConnell le dio nombre. Si se representa gráficamente a lo largo del tiempo, tiene la forma de un cono: ancho a la izquierda, donde se sabe menos, y estrechándose hasta un punto a la derecha, donde el trabajo está casi terminado y ya no queda nada que pueda salir mal.
Por qué es importante para la estimación
La mayor parte de las dificultades a la hora de realizar estimaciones se debe a que se exige una estimación puntual en la parte más ancha del cono. Alguien pregunta «¿cuánto tiempo llevará el nuevo sistema de facturación?» antes de que se haya escrito una sola línea de código, recibe como respuesta «unos tres meses» y lo toma como un compromiso. El cono indica que, en realidad, esa cifra se sitúa entre seis semanas y nueve meses; y fingir lo contrario solo sirve para posponer la decepción a más adelante.
Esta es precisamente la razón por la que el método ágil estima el tamaño relativo en lugar de comprometerse con fechas concretas. Los puntos de historia y el planning poker no se oponen al «cono», sino que lo aceptan. Una rápida evaluación relativa («esto es más grande que lo que entregamos en el último sprint») es el grado de precisión realista del que se dispone en una fase temprana, y la velocidad convierte eso en una previsión con un margen de variación, en lugar de una falsa promesa.
Cómo estrechar el cono
El cono se estrecha cuando se eliminan las incógnitas, no cuando se añade margen de maniobra. Por orden de influencia:
- El «spike» es la incógnita más arriesgada. Un spike con un plazo limitado permite obtener información, que es lo único que realmente reduce el margen de incertidumbre.
- Perfeccione el proceso hasta que dejen de surgir preguntas. Una historia sobre la que el equipo sigue planteando preguntas se encuentra en la parte más ancha del cono; unos criterios de aceptación bien definidos la desplazarán hacia la derecha./guides/agile-estimation-guide/acceptance-criteria/
- Divídalo. Las historias más pequeñas se sitúan más abajo en el cono: cada parte se comprende bien, por lo que cada estimación es más precisa que una estimación para el conjunto.
- Revise su estimación cuando haya aprendido algo. Revisar la estimación a medida que se va reduciendo el cono es honesto; hacerlo para alcanzar un objetivo, no lo es.
El cono no es una excusa para inflar las cifras
La conclusión errónea es: «Todo es incierto, así que hay que duplicar todas las estimaciones». El margen de seguridad desplaza todo el cono hacia arriba sin reducirlo: se sigue haciendo una estimación, solo que de forma pesimista. La respuesta adecuada ante un cono amplio es, o bien resolver la incertidumbre (concretar, refinar, dividir), o bien comunicar el rango con honestidad y comprometerse a volver a realizar una estimación.
Preguntas frecuentes
¿Qué es el «cono de incertidumbre»?
El «cono de incertidumbre» describe cómo el margen de una estimación es más amplio al inicio de un trabajo y se va reduciendo a medida que este avanza y se van resolviendo las incógnitas. Al principio, una estimación puede desviarse considerablemente en cualquier dirección; cuando se comprende bien el trabajo, el margen se reduce hasta acercarse al resultado real.
¿A quién se le ocurrió el «cono de incertidumbre»?
Esta figura fue observada por primera vez por Barry Boehm a principios de la década de 1980 como una relación entre el software y los costes, y posteriormente Steve McConnell la denominó «cono de incertidumbre» y la popularizó en el ámbito del desarrollo ágil y la estimación de software.
¿Cómo se aplica el «cono de incertidumbre» a la estimación ágil?
Esa es la razón por la que el método ágil estima el tamaño relativo en lugar de comprometerse con fechas desde el principio. Los «story points» y el «planning poker» parten de la base de que las estimaciones iniciales son amplias, sacrifican una precisión falsa a cambio de una visión relativa rápida y se vuelven a realizar a medida que el «cono» se va estrechando a través del refinamiento, las fases de prueba y el trabajo entregado.
¿Cómo se reduce el «cono de incertidumbre»?
No hay que inflarlo: hay que resolver las incógnitas que lo hacen tan amplio. Analice a fondo la parte más arriesgada, perfeccione la historia hasta que dejen de surgir preguntas, divídala de modo que cada parte resulte comprensible y vuelva a hacer una estimación una vez que haya aprendido algo. El cono se estrecha cuando se elimina la incertidumbre, no cuando se infla la cifra.
Lecturas relacionadas
- Estimación relativa frente a absoluta — por qué el dimensionamiento relativo se mantiene tras el cono.
- División de historias de usuario — «spikes» y «splits», las estrategias que permiten obtener la información necesaria para reducir el rango.
- Velocity — convertir una estimación inicial y amplia en una previsión con un intervalo.
- Guía de estimación ágil — el conjunto completo de recursos sobre estimación.
- Planning Poker gratuito para equipos ágiles — obtenga la lectura rápida y relativa que requiere el «cono».