El cono de incertidumbre en la estimación ágil
Las estimaciones iniciales presentan un amplio margen de variación porque se trata de un trabajo desconocido, 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 primera estimación es la menos precisa, 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 hay que 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 forma de cono: ancho a la izquierda, donde menos se sabe, 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 considera 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»; 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, 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. 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 proyecto hasta que dejen de surgir preguntas. Una historia sobre la que el equipo no deja de plantear 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 sus estimaciones cuando haya aprendido algo nuevo. Revisar las estimaciones a medida que se estrecha el cono es una actitud honesta; hacerlo para alcanzar un objetivo, en cambio, no lo es.
El cono no es una excusa para inflar las cifras
La conclusión errónea es: «Todo es incierto, así que duplique todas las estimaciones». Al inflar las cifras, se desplaza hacia arriba todo el cono sin estrecharlo; sigue siendo una conjetura, solo que pesimista. La respuesta adecuada ante un cono amplio consiste, o bien en resolver la incertidumbre (concretar, refinar, dividir), o bien en 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 presentar un margen de error considerable en cualquier dirección; cuando se comprende bien el trabajo, ese 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 estimar 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 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 resiste la prueba del cono.
- División de historias de usuario: pruebas piloto y divisiones, las estrategias que permiten obtener la información necesaria para reducir el rango.
- Velocity: convertir una estimación inicial y general en una previsión con un rango.
- 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».