El cono de la incertidumbre y Scrum

En la gestión de proyectos, el cono de Incertidumbre describe la evolución de la medida de incertidumbre durante la realización de un proyecto. La incertidumbre no solo se reduce conforme pasa el tiempo, sino que también disminuye su impacto en la gestión de riesgos, especialmente en la toma de decisiones.

El término “Cono de incertidumbre” es usado en la Ingeniería de Software, cuando los ambientes técnicos y de negocios cambian de manera rápida y repentina. Sin embargo, el concepto, bajo un nombre diferente, es también un principio básico establecido de la Ingeniería de costos. La mayoría de los ambientes cambian de manera lenta, tanto que pueden ser considerados como “estáticos” para la duración de un proyecto típico, y, por ende, los métodos tradiciones de gestión de proyectos se enfocan en lograr un entendimiento completo del ambiente a través de un análisis y planeación cuidadosos. Mucho antes de que se hagan inversiones significativas, la incertidumbre es reducida a un nivel en el cual los riesgos pueden ser eliminados o tratados de manera cómoda.

En este tipo de ambiente, la incertidumbre se reduce rápidamente al comienzo del proyecto, y su forma ilustrada de “cono” es menos apreciable.

Sin embargo, la industria de software es muy volátil, y hay una presión externa para incrementar el nivel de incertidumbre al paso del tiempo. El proyecto debe trabajar activa y continuamente para reducir el nivel de incertidumbre.

El cono de incertidumbre es limitado y reducido a través de la investigación y la toma de decisiones, lo cual remueve las fuentes de variabilidad del proyecto. Estas decisiones tratan sobre el alcance y lo que está o no incluido en el proyecto. Si éstas cambian durante el desarrollo del mismo, el cono de incertidumbre se hará más extenso.

No nos engañemos, estimar al principio de un proyecto es un “marrón”. Nuestro conocimiento sobre el cliente, el producto que supuestamente quiere e incluso la tecnología a utilizar puede ser muy limitado. Sin embargo, el cliente (interno o externo a la empresa) nos pide una fecha de entrega, lo más exacta posible: ¿Cuándo va a estar lista mi nueva app? ¿Cuándo lanzaremos la versión 5.3?

En desarrollos de producto que usan el framework Scrum, la pregunta sigue siendo de vital importancia, puesto que la respuesta determina en buena parte el número de Sprints que el cliente va a tener que financiar.

Un concepto que siempre útil para al menos intentar suscitar cierta comprensión por parte de mis interlocutores es el del cono de la incertidumbre. Esta puede ser una más dentro de tu caja de herramientas como Scrum Master o Product Owner. El cono de la incertidumbre es una forma gráfica de expresar que, a medida que un proyecto avanza, la precisión de nuestras estimaciones aumenta. Al arrancar, no obstante, la variabilidad de las estimaciones siempre será alta, puesto que sabemos bastante poco sobre el producto en cuestión. Y lo será incluso si invertimos un gran esfuerzo en realizar las estimaciones. Conforme avanzamos en el trabajo de desarrollo y obtenemos más y más información, aprendiendo en cada Sprint, seremos capaces de acotar dicha variabilidad.

En la imagen mostramos el cono de la incertidumbre con el rango definido originalmente por Barry Boehm en 1981 (¡hace casi 40 años!), que se refería a un proceso tradicional o Waterfall. De acuerdo con estos valores, al comienzo de un proyecto la estimación típicamente varía entre un 60% y un 160%. Es decir, un proyecto estimado en 20 semanas puede tardar entre 12 y 32 semanas. Abajo recogemos una adaptación de esta misma idea en el ámbito de Scrum, utilizando un rango de variabilidad entre el +75% y el -25% (y, tranquilo, si nunca has sido testigo del milagro del -25%, ya somos dos 😉).

¿El cono de la incertidumbre implica que estimar en Scrum es inútil?

Rotundamente no. El mero ejercicio de hacer la estimación del Producto Backlog inicial nos permitirá entrar en materia, empezar a tener conversaciones útiles sobre cómo vamos a implementar ese Backlog. Además, al menos deberemos ser capaces de proporcionar no una fecha de entrega exacta (que sería darnos un “tiro en el pie”), sino un rango de fechas basado en la información de la que disponemos.

Eso sí, no hay que volverse locos: por mucho que dediquemos a estimar, sin de verdad “arremangarnos” difícilmente conseguiremos disminuir su variabilidad.

Una vez que hayamos hecho dos o tres Sprints, nuestras estimaciones empezarán a ganar precisión y la amplitud del rango se irá reduciendo, como indica el cono de la incertidumbre.

El Cono y el DeTeam

La Guía Scrum dice que el equipo de desarrollo,durante la Sprint Planning, tiene que dividir el trabajo en partes menores de un día.

Teniendo en cuenta que la Daily es un evento en el cual el DevTeam se reune para hacer una ajuste del plan revisando el avance de los trabajos, el trabajo pendiente y los impedimentos, ¿entiendes la relación entre la duración de las tareas que determina Scrum y la Daily?.

Ojo con los conos dentro del cono…

En mi experiencia, lo que sucede con más frecuencia de la que me gustaría es que la tendencia del cono se cumple, pero pueden surgir incertidumbres inesperadas que afecten a ciertas funcionalidades.

¿Y qué pasa si pongo un microscopio sobre los conos verdes que representan las HdU (Historia de usuario)? Pues se ven conos más pequeñitos dentro de ellas, las tareas de menos de un día. Estas tareas son a las historias lo que las iteraciones cortas a los proyectos, con el mismo comportamiento y las mismas consecuencias.

¿Y qué pasa cuando las tareas que abordáis son mayores que un día estimado, 5 por ejemplo? Pues que aumentáis el alcance, la variabilidad del cono puede llevaros a terminar mucho tiempo después de esos 5 días y el tiempo de reacción o aprendizaje se sitúa muy cerca del final del Sprint. Resultado: constantemente el equipo deja HdU sin terminar al finalizar el Sprint, la rutina es llevarse siempre HdU de un Sprint a otro.

Tened en cuenta que cuando el plan del DevTeam admite una tarea de 5 días, nadie va a poner peros al avance de la tarea hasta el 5º día, siempre tendemos a darnos el espacio de los 5 días aunque no tengamos claro si vamos bien. Actuando así retrasamos la revisión y ajuste del plan, tardamos más en reaccionar si algo no va bien, somos menos adaptables al cambio. Luego decimos que Scrum no funciona, igual si nos ajustamos al framework obtendríamos los beneficios que no vemos.

En realidad todo el mundo entiende el concepto y está de acuerdo con lo que nos cuenta el Cono de Incertidumbre, sin embargo el Dev Team, cuando tiene que dividir su trabajo en partes menores de un día para poder revisar y reajustar el plan en la Daily encuentra todos los inconvenientes y restricciones para hacerlo.

Recuerdo, por ejemplo, un proyecto en el que, después de un puñado de Sprints, cuando parecía que veíamos la luz al final del túnel, la estimación relativa al servicio de mensajería entre usuarios de una app se disparó de 2 días a casi 4 semanas, puesto que había que hacer que dicha herramienta fuera compatible con legacy code o código heredado a cualquier código que no esté cubierto por pruebas automatizadas. Por difícil que parezca, puede que te des cuenta de que actualmente estás escribiendo código heredado para los próximos meses.

Aunque seas tú quien lo escriba, el mes que viene, nadie recordará exactamente para qué se creó este trozo de código, sólo que podemos minimizar si tenemos una gran unidad, integración y pruebas de aceptación.

En un entorno ágil, las pruebas son la documentación más importante. He visto en algunas organizaciones en las que se informaba de más de tres errores críticos por equipo de desarrolladores a la semana, lo que destruye cualquier posibilidad de seguir un plan en el sprint.

Esas incertidumbres “sobrevenidas” pueden “ensanchar” el cono y llevarnos a escenarios nada agradables. En mi opinión, nunca se puede ser demasiado cauto a la hora de dar un rango de fechas, que habremos de revisar Sprint a Sprint, asegurando la máxima transparencia, para bien o para mal. La Sprint Review, es un espacio idóneo para que el Product Owner comparta esta información con stakeholders y todo el Equipo Scrum.

El Cono y las estimaciones

Tomando como referencia este cono podemos decir que los equipos Scrum abordan un Sprint estando cercanos a la vertical de los Requerimientos completados. Algunos equipos tendrán más definición que otros, todo dependerá del contexto completo en el que están inmersos y de lo que hayan incluido en su Definition of Ready (DoR). Este cono expresa una variabilidad de entorno a 1,65x en ese momento, de modo que:

• Un trabajo estimado en 4 semanas puede llevar a: 20 días x 1,65 = 33 días = 6.6 SEMANAS.
• Un trabajo estimado en 3 semanas puede llevar a: 15 días x 1,65 = 24,75 días = 5 SEMANAS.
• Un trabajo estimado en 2 semanas puede llevar a: 10 días x 1,65 = 10,65 días = 3.3 SEMANAS.
• Un trabajo estimado en 5 días puede llevar a: 5 días x 1,65 = 8,25 días.
• Un trabajo estimado en 3 días puede llevar a: 3 días x 1,65 = 4,95 días

Dedicado a vosotros, los equipos que no tenéis determinada una duración máxima para la HdU durante el Sprint y cuya único límite es “que quepa en el Sprint”:

• ¿Cuánto dura vuestro Sprint? ¿2 semanas?
• ¿Qué riesgo estáis asumiendo cuando determináis HdU de 2 semanas?: que se vaya a 3.3 semanas.
• ¿De cuánto debería ser el máximo de duración de las HdU en vuestro caso?: exceder una semana es casi llevarlo al límite.
• ¿Entendéis el motivo por el cual arrastráis trabajo de un Sprint a otro constantemente?
• ¿Cómo podéis trabajar con ese nivel de frustración y ansiedad de no cumplir el compromiso nunca?. Igual está en vuestra mano hacer más cosas de las que pensáis para que todo funcione mejor y el trabajo sea algo realmente gratificante de hacer.

El motivo de estimar en proyectos es minimizar el riesgo y la variabilidad asociado al tamaño del trabajo a realizar y la incertidumbre de lo que hay que hacer, no para determinar el final del desarrollo… para esto último mejor la Bola de Cristal. A partir de aquí tú decides si es necesario estimar en tu entorno laboral.

• Si el comportamiento de las personas que intervienen tiene interiorizado este concepto y los bloques de trabajo son generados de forma natural acordes al concepto explicado, entonces no necesitarás estimar.
• Si, por el contrario, la división del trabajo en partes no se ajusta y suele manejar tamaños fuera del concepto que hemos visto, entonces te puedes proteger del riesgo asociado estableciendo los límites de tamaño en el DoR de tu nivel de abstracción. Estimar es una práctica para minimizar el riesgo