Una de las preguntas recurrentes en los cursos de Scrum es relativa a las estimaciones. Esto no es novedad. Las organizaciones quieren tener una indicación de cuanto esfuerzo llevará hacer algo antes de decidir introducirlo dentro de su producto. Es una petición razonable.
Ya hemos hablado en el pasado de estimaciones. Desde cómo hacer estimaciones conjuntas en SAFe a cómo en Scrum no es necesario ni planning póquer ni historias de usuario, pasando por la verdadera importancia de la velocidad en Scrum y el movimiento #NoEstimates.
Hoy quiero hablar de las tres estrategias básicas de estimación, su utilidad y cómo sacarles partido en entornos complejos: Estimaciones absolutas, estimaciones relativas y estimaciones basadas en flujo.
Estimaciones absolutas
La guía de Scrum cambió el lenguaje hace unos años para dejar de hablar de estimaciones y ahora solamente señala que aquellos elementos que se pueden hacer en un Sprint están listos para ser seleccionados en un Sprint Planning.
Las estimaciones absolutas son las más tradicionales y pueden ser basadas en tiempo o esfuerzo. La famosísima recopilación de ensayos “El mítico hombre-mes” ya describía hace 50 años la problemática de añadir gente a un proyecto de desarrollo de Software que iba tarde: “Añadir gente a un proyecto que va retrasado solo hará que se retrase más“.
También abordaba en la problemática de estimar sistemas complejos.
El problema reside en que subdividiendo un sistema en partes más pequeñas y estimando cada una de ellas por separado ganamos una falsa sensación de control e ignoramos la complejidad que supone hacer que todas las partes funcionan entre sí.
Así, se han perfeccionado técnicas como los diagramas de Gantt, que pretenden establecer un cronograma de acciones para que los distintos actores y actividades se coordinen. El análisis de puntos función va más allá, estableciendo una metodología para medir la productividad del Software y ell coste asociado con el desarrollo y el mantenimiento.
Ninguna de estas técnicas tiene en cuenta la variable fundamental en el desarrollo de un producto: la complejidad.
A efectos prácticos sería como estimar cuanto vamos a tardar en realizar un viaje en coche sin tener en cuenta el tráfico.
Estimaciones relativas
Afortunadamente con la popularización de las metodologías ágiles se ha expandido la noción de que las estimaciones absolutas, por precisas que se pretendan, son inútiles.
A raíz de la publicación y uso de eXtreme Programming, el uso de estimaciones basadas en relativizar la importancia de unos elementos frente a otros se ha vuelto más popular, con técnicas como Planning Poker y T-Shirt Sizing.
El objetivo de estas técnicas, a diferencia de las usadas en estimaciones absolutas no es el obtener una visión precisa del esfuerzo sino debatir las complejidades asociadas con el desarrollo del producto. El resultado es el debate, no el número.
Dicho de otra manera, con estimaciones relativas es dificilmente posible hacer un traslado a horas (o a euros/dólares) del esfuerzo a realizar en el desarrollo de un producto.
El problema, de nuevo, es la falsa sensación de control. Teniendo tallas o números podemos estar tentados de hacer algún tipo de equivalencia. Aunque quizás en un solo equipo puede funcionar, cuando escalamos el sistema se rompe.
Esto es debido a la subjetividad de estas técnicas. Dos personas estiman la misma tarea de distinta manera en función de su esfuerzo. Usan distintos sistemas de referencia. Si trabajan juntas pueden llegar a un consenso, pero cuando se añaden más actores pierde su utilidad.
Una de las maneras de evitar este problema es intentar establecer un sistema de referencia. Un consenso común. Sin embargo esto nos sigue alejando del objetivo, que es tener un mejor entendimiento de los retos a abordar.
Estimaciones de flujo
Con la popularización de Kanban, de los métodos basados en flujo y del uso de Kanban y Scrum juntos también se han popularizado los sistemas de estimación basados en simulaciones de Monte Carlo.
Dan Vacanti, Professional Scrum Trainer y fundador de Actionable Agile ha facilitado la popularización de estas técnicas a través del desarrollo de productos para mejorar a predicibilidad.
La propuesta de Vacanti es contar el número de elementos que entregamos y usando este dato lanzar una serie de cientos o miles de simulaciones usando el método de Monte Carlo para saber cuando algo está finalizado.
En la imagen podemos observar como utilizando solamente al throughput histórico podemos obtener una estimación de cuando una serie de ítems estarán terminados.
Lo interesante de este método es que, a diferencia de los métodos absolutos o relativos, no necesita estimar el esfuerzo de un elemento, ya que precisamente tiene en cuenta las variables que no podemos controlar y que son las que le aportan el factor de complejidad al sistema.
En otras palabras, este método tiene en cuenta el tráfico para calcular el tiempo de llegada al destino en lugar del modelo, potencia o color de nuestro coche.
Implementar este sistema es más sencillo de lo que parece. En el github de Focused Objective puedes encontrar suficiente material para empezar a estimar de esta manera.
Si de verdad necesitas hacerlo, no estimes
Aquí merece la pena hacernos una pregunta: ¿Por qué estimar?
De manera sencilla, las estimaciones son un requerimiento para tomar decisiones en una organización. Hace tiempo vimos como quizás esta toma de decisiones es lo que más impacta en la agilidad de una organización. Pero si analizamos en profundidad, el factor humano del control es, para mí, el factor determinante.
Queremos control. Y por eso estimamos. Y cuando lo hacemos mal buscamos mejores maneras de estimar. No funciona. Y volvemos a empezar.
Mi recomendación para cualquier organización es que si tienen problemas con las estimaciones intenten abandonar las prácticas tradicionales y se muevan hacia estimaciones basadas en flujo.
Las estimaciones conllevan un gran esfuerzo. No solamente de tiempo sino también de moral. Entre las quejas más habituales de los Developers está el requerimiento de realizar estimaciones precisas. Si ponderamos el beenficio potencial con el coste de realizarlas, el resultado es netamente negativo.
Si además nos movemos en un entorno de cambio rápido, tiene aún menos sentido.
Deja una respuesta