Estimaciones, ¿realidad o ficción?

Las estimaciones, ese gran diablo que se cuela en nuestro día a día y nos marca. Algunas de las preguntas que más me han hecho las personas que se están iniciando en el mundo Agile son “¿cómo estimáis en Agile?” o “¿cómo hacéis para decirle al cliente cuánto vais a tardar?”.

En Agile, la fase de estimación ha madurado. Partimos de que el software es complejo y, por tanto, hay incertidumbre. Es imposible saber qué va a ocurrir. Los profesionales del software lo van descubriendo proyecto tras proyecto. Es algo que solo nos puede decir la experiencia.

Hagamos un repaso de las distintas técnicas de estimación y veamos un pequeño análisis de cada una de ellas para entender mejor esta fase de Agile.

1 Estimación en horas

La estimación basada en horas es la más común. Básicamente es indicar el tiempo que vamos a tardar en realizar una tarea. Con la estimación en horas solemos cometer varios errores. El primero que cometemos es que nos preguntan un tiempo y… ¡damos un tiempo!

Pongamos un ejemplo, imagina que te preguntan “¿cuánto tiempo tardas en ir de Madrid a Barcelona en coche?”**. Lo primero que hacemos es pensar y rápidamente decimos “unas 6 horas”.

Imagina que ahora nos dicen *“¡Perfecto! Pues sales mañana viernes a las 14:00 h, con 2 bebés en el coche, con un Renault 5 y sin poder usar peajes”. *Lo típico es que nuestra reacción sea la siguiente: “¡No! Con esas condiciones sería más tiempo”.

Este caso concreto lo vemos muy a menudo, estimamos un tiempo basado en una idea sin conocer los riesgos que la tarea lleva asociada. Normalmente lo resolvemos con el denominado “colchoneo”.

El “colchoneo” es hacer la siguiente reflexión: “Hemos estimado este proyecto en 1.000 horas, vamos a decir 1.300 por si pasa algo”.

El problema del “colchoneo” es que no es transparente, no es honesto, en el fondo estás engañando. Este tipo de prácticas ocurre porque muchas veces ponemos el foco en negociar en vez de en producir software con valor.

En el mundo tradicional esto se resuelve con el Plan de Riesgos, que recoge todo lo que creemos que podría ocurrir y el coste que conllevaría si ocurrieran. De esta manera tratamos de equivocarnos lo menos posible.

El problema de la estimación en horas con Plan de Riesgos es que, en entornos complejos donde no es posible predecir lo que va a pasar, no funciona. Por desgracia, para nosotros, el software es complejo y en estos entornos la única manera de funcionar es “probar-sentir-responder”.

2 Estimación en puntos o “puntos de historia”

Un “punto de historia” representa una cantidad de trabajo que tenemos que realizar. Hay equipos que confunden la técnica de estimación por horas y la estimación en puntos porque asocian tiempo a los puntos: “un punto es un día de trabajo”. Evidentemente, si hacemos esa analogía realmente estamos estimando en tiempo.

Veámoslo a través de un ejemplo. Imaginemos que tenemos que pintar una habitación de 100 metros cuadrados. Un pintor experto, que pinta 50 metros al día, tardará mucho menos que un pintor que hace 10 metros al día. ¡Pero para ambos es el mismo trabajo! En este ejemplo, 1 metro cuadrado sería 1 punto. Esta es la ventaja de los puntos, es más fácil llegar a un consenso en equipo.

La estimación en puntos es una estimación relativa. Esto significa que se estima las tareas comparándolas con las ya estimadas. Si decimos que una tarea es 3 puntos respecto a otra de 1 punto, lo que estamos transmitiendo es que llevará 3 veces más trabajo.

Para hacer estimación en puntos se utiliza la técnica planning poker. Es muy útil porque nos permite tener conversaciones sobre cómo hacer los ítems del backlog.

El mejor consejo que puedo dar para la estimación en puntos, es que solo se estimen a nivel de Historia de Usuario o de Product Backlog Item.

Lo ideal es que cojamos un ítem y lo dividamos en las tareas que creamos que hay que hacer. Después, entre todos, estimamos el trabajo total de ese ítem, aunque cada uno de nosotros haga una parte.

3 Estimación en tallas

Dado que a muchos equipos les cuesta pasar de horas a puntos porque acaban asociando tiempo a los puntos, existe una técnica intermedia: asociar tallas de camiseta a los ítems del backlog: XS, S, M, L, XL.

Ya que no se pueden comparar unas tallas con otras a nivel numérico, hay quien contabiliza las tallas a posteri. A cada talla se le asocia un número siguiendo la serie de Fibonacci. Una vez el equipo madura, es el momento de cambiar al sistema de puntos.

Hay algo que no podemos perder de vista en esta técnica. Si un *ítem *se marca con una determinada talla, el mismo ítem (pasado el tiempo) se debe marcar con la misma talla, aunque ahora tengamos más expertise.

El motivo es el mismo que con el ejemplo del pintor, la habitación siempre será la misma, independientemente de que ahora pintemos más rápido.

4 Estimación en PBIs

¡Aquí viene la estimación estrella! Hace tiempo aprendimos esta técnica a través de Jerónimo Palacios y es la apuesta más científica. Recordemos que Scrum se basa en el empirismo: a medida que ganamos experiencia, podemos ganar en predictibilidad.

La técnica de estimación en PBIs mide la cantidad de Product Backlog Items (PBIs) que somos capaces de hacer por Sprint. Lo primero que tendemos a pensar es ¡dependerá del tamaño de cada PBI!

Imaginemos que todos los PBIs tuvieran un tamaño semejante, esta técnica sería ideal, nos diría con un intervalo nuestra capacidad de trabajo en un Sprint.

Por ejemplo, después de varios Sprints podemos asegurar que nuestro equipo hace [7-11] PBIs por Sprint. Con este dato nuestro Product Owner podrá hacer proyecciones sobre el futuro del producto.

Vayamos al peor de los casos: todos los PBIs son diferentes. Lo que ocurrirá es que nuestra velocidad se mediría en un intervalo mucho mayor, por ejemplo [4-14]PBIs por Sprint. En este caso somos mucho menos predecibles.

Si queremos mejorar nuestra predictibilidad, nuestro Product Owner tendrá que poner el foco en agrupar PBIs pequeños y en dividir los grandes para conseguir esa homogeneidad (y así mejorar el dato).

¡Aquí está la clave! Nuestro Product Owner deberá determinar cómo de predecible quiere ser. Si quiere ser más fiable tendrá que homogeneizar. Muchos pueden pensar “si mi equipo ha ido haciendo entre [7-11]PBIs y, de pronto el Product Owner introduce PBIs muy grandes, al equipo no le dará tiempo”.

Recordemos que en Scrum se hacen previsiones y no compromisos. Si de pronto nos piden PBIs muy grandes, lo que ocurrirá es que ese Sprint haremos menos de previsto y nuestro dato se actualizará a la nueva realidad.

La gran ventaja de este método es que evita que nos “tiremos a la piscina” sin haber escrito una línea de código. Al ser un método basado en la experiencia, necesita rodaje de Sprints para empezar a funcionar.

Realmente los puntos y las horas también, pero es más probable que demos un dato demasiado pronto y que generemos frustración al no cumplirlo.

Conclusión

La conclusión que podemos sacar es sencilla: se puede estimar, pero utilizar la estimación como un indicador de felicidad en el cual si cumples con lo que dijiste te premio y, en caso contrario, te castigo si no funciona. Estimar sirve para muchas cosas, pero no para marcar el éxito de un proyecto. Es más, puedes cumplir con tu estimación y que nadie quiera ese software.

Podemos decir que las estimaciones son importantes en entornos controlados. En entornos complejos invertir mucho tiempo estimando cosas que van a cambiar, que no están definidas o que desconocemos, genera mucha infelicidad. Centrémonos en sacar producto y, más que estimar, usemos nuestra experiencia y no nuestra imaginación.