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 utilizan 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 he encontrado ú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 de portada 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.

Ojo con los conos dentro del cono…

En nuestra experiencia, lo que sucede con más frecuencia de la que nos gustaría es que la tendencia del cono se cumple, pero pueden surgir incertidumbres inesperadas que afecten a ciertas funcionalidades. 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 una plataforma legacy que todos amábamos… 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, a propósito, es un espacio idóneo para que el Product Owner comparta esta información con stakeholders y el Equipo Scrum.