Estimar: una verdad incómoda

¿Estimar o no estimar? El pasado 12 de febrero, celebramos un evento llamado Agile 20 Aniversario, donde reunimos a 13 referentes de Agile español e internacional. Uno de los asistentes más reconocidos, Javier Garzás, comentó que, al haber pasado 20 años, ya existe “Agile viejuno”, ciertas prácticas que hoy en día ya se ven como anticuadas.  

Una de ellas son los puntos de historia. Durante muchos años, hemos pensando que eran una herramienta Agile infalible. Cierto es que, desde mi punto de vista, es la técnica de estimación menos negativa. Sin embargo, sigue siendo una herramienta de estimación prescriptiva, lo que significa que la usamos para tomar decisiones demasiado temprano, sin datos y con excesiva incertidumbre. Si nos aventuramos a predecir el futuro en base a datos inventados (como los puntos de historia), entonces seguimos con la mentalidad tradicional de predecir y controlar. 

Teoría y realidad sobre estimar

Cuando toca estimar, todo es maravilloso. Tenemos todo el tiempo del mundo y parece que nos lo vamos a comer. Esto es típico en equipos con Sprints de 3 o 4 semanas. Empiezan a introducir elementos en el Sprint Backlog como “si no hubiera un mañana”. Y, al acabar el mismo, descubren que solo han alcanzado el 60% de lo previsto. Este hecho, aplicado a grandes productos con grandes entregas, puede hacer que se dilate en el tiempo meses, lo que genera una gran frustración en la organización y muchísima tensión improductiva. 

La teoría es que una release nos va a llevar tres meses, pero después se duplica… Cuando nos preguntamos por qué, encontramos multitud de factores habituales: 

• Tiempo perdido en montar el equipo que no tuvimos en cuenta.
• Bloqueos contínuos por parte del cliente.
• Cambios de alcance, esto es Scrum y no se puede decir no. 
• Cambios en las prioridades, lo que nos hace abandonar desarrollos arrancados. 
• Validaciones de los clientes, que tienen que sacar tiempo y nos hacen esperar. 
• Tecnología con la que no estamos familiarizados. 
• Cambios en el equipo, solemos tener una rotación elevada y pueden abandonar compañeros. 

Esto es solo una pequeña muestra de los miles de factores que afectan a un equipo y que provocan que un equipo se retrase en su entrega respecto a lo estimado. 

Planes de Riesgos

Sin embargo, esto no es la primera vez que ocurre. Ya llevamos muchos años de Ingenieros del Software para habernos dado cuenta de que, cuando abordamos un desarrollo, pueden ocurrir multitud de hechos que nos retrasen. Para resolver esto, el Project Management Institute, recomienda utilizar planes de riesgos. Un plan de riesgos trata de evaluar todo aquello que podría afectarnos, de cara a planificar respuestas o acciones que eviten o minimicen el daño de estos factores. 

Un equipo con experiencia no solo hará una estimación sino que evaluará todos estos riesgos que se pueden disparar y sumará esos tiempos. El problema es que hay tal cantidad de cosas que podrían ocurrir, que los tiempos se pueden disparar… ¡por cuatro! 

Esto, que puede parecer exagerado, no lo es, hemos visto a equipos alargarse un año respecto a una estimación de dos meses. Y es debido a la cantidad de factores que no dependen de nosotros, más aún en organizaciones muy departamentales y funcionales. 

Cuando damos un número, más cercano a la realidad, nos dirán que “es muy caro”, “que así no se puede”,  y nos pedirán que seamos más optimistas y que reduzcamos. Sin embargo, al dar una fecha, tendremos un compromiso que, al no ser libres para dar uno realista nos puede generar mucha frustración. 

Alternativa Scrum para no tener que estimar

Lo peor de todo no es la estimación, es el coste de la misma. Invertimos días en definir requisitos de cosas que no queremos ahora mismo, pero que tienen que estar definidas para estimar. A esto, sumamos las estimaciones, hay que pensar muy bien lo que vamos a construir, diseñar el sistema y tomar las decisiones adecuadas. Todo eso es mucha energía, invertida en partes del producto que aún no sabemos si queremos, pero que tenemos que definir para poder presupuestar el coste total. 

Imaginemos que se cumple nuestra estimación, algo que rara vez ocurre, lográndolo, incluso, con calidad y sin disparar el coste por haber añadido más personas, pero… ¿Y si nadie quiere lo que hemos construido? Una vez más, nos estrellamos estrepitosamente. Una fecha es un input, un dato más a tener en cuenta, pero no puede ser el fin que marque el éxito de un equipo, porque no garantiza que se dé un buen resultado o un buen servicio. 

Scrum plantea una alternativa diferente. Definamos claramente qué queremos conseguir. ¿Cuál es la métrica que nos dirá que hemos tenido éxito: más usuarios, monetización, transacciones, uso del producto, ahorro de tiempo en los procesos…? Sea la que sea, debemos tener claro las métricas que nos preocupen. Una vez definidas, tenemos varios eventos donde vamos a inspeccionar y vamos a adaptar nuestro trabajo para mejorar esas métricas. Esta es la clave del éxito, el poder tomar decisiones en base a lo que, realmente, nos garantiza el éxito del producto. 

Cómo podemos evolucionar

Si queremos evolucionar nuestro equipo de alcance-fecha a uno de medir-adaptarse, nuestro consejo es empezar por mantener fechas y estimaciones, si se intenta un cambio “radical” puede producirse un desastre. Ahora bien, mientras se dan esas estimaciones, hay que empezar a medir: midamos lo que se tarda en hacer las cosas. Midiendo lo que se tarda, podremos dar predicciones basadas en estadística, de manera que podamos sustituir las estimaciones por los datos reales del equipo. 

Además, debemos definir que métricas de valor pueden ser interesantes, y tratar de conseguir datos sobre ellas cuanto antes. Cuando vayamos a hablar de fechas de entrega y métricas tradicionales, como la productividad, enseñemos también las métricas de valor. A veces, se enciende una bombilla y alguien empieza a entender el valor de las segundas sobre las primeras. 

Por último, tenemos que centrarnos en la Sprint Review, el evento clave de Scrum donde inspeccionamos el resultado de nuestro producto. Debemos lograr  que asistan las personas que más se impacientan por el producto y que más bloquean. Intentemos que se mantengan conversaciones sobre cómo generar valor y, no tanto, sobre si llegamos a una fecha concreta. 

Las estimaciones van a estar ahí por muchos años, pero si queremos ser ágiles y competir en entornos complejos, como el software, debemos empezar a centrarnos en el valor de lo que producimos. 

Y tú, ¿estimas o mides?