Aprendiendo a estimar

Por Adrián Ferrera González

¿Cuántas veces has empezado en un proyecto y en la primera reunión de estimación, no has sabido qué decir? ¿Has pedido no participar en esta reunión de estimación por desconocimiento?

Esto ocurre más a menudo de lo que crees, y es que, cuando estimamos nos enfrentamos a un gran dilema; a un compromiso rodeado de incertidumbre, que lo que busca no es fiscalizar, pero sí dar una visibilidad del esfuerzo que puede conllevar una tarea, de cara a una buena planificación de producto.

Las estimaciones dan una sensación de falso control. El poder etiquetar una tarea, transmite una sensación de seguridad y de adquisición de compromiso, que no es otra cosa que una falacia. Una estimación no es una fecha, es un indicador, pero con posibilidad de cambio. Es decir, esa sensación de seguridad se desdibuja más y más cuanto menos precisa es la estimación.

Ahora bien, la información provista en una sesión de estimación es muy importante, a pesar de no ser una verdad absoluta. La cuestión es “¿cómo la llevamos a cabo?”

Tomar puntos de referencia

- “Esto es un uno”
+ “Pues para mi es cinco”

Es muy común encontrarnos con esta situación constantemente en sesiones de estimación, pero… ¿Cuál es el problema? Nuevamente sesgos. En el Agile Open Spain de 2022, Fernando Bogas Pomares, nos propuso el siguiente ejercicio:

Sin buscar en Internet, dime, bajo tu criterio: ¿Cuánto mide la Torre Eiffel?

Probablemente, el valor pueda estar más cerca o lejos de la realidad, sin embargo, cuando pones el valor en común con el resto de participantes, se ve una disparidad en cuanto a los resultados. (No lo mires aún).

Ahora bien, si comparamos una foto de la Torre Eiffel y una foto de la Gran Pirámide de Guiza donde puedas tener un punto de referencia, y decimos que la pirámide mide 139m. ¿Cuánto dirías que mide ahora la Torre Eiffel?

Muy probablemente, ahora seamos capaces de dar un valor mucho más aproximado de la altura real, ya que tenemos un punto de referencia con el que comparar.

¿Y si añadimos más información a nuestra ecuación? Vamos añadir una comparación con el Empire State Building el cual mide 449m:

Teniendo estos puntos de referencia, seguro que ahora somos capaces de estimar cuál es la altura de la Torre Eiffel con mayor precisión.

Como nota adicional, la Torre Eiffel mide 324m ¿Te has acercado?

La clave está en tener puntos de referencia. Cuando estimamos, el equipo tiene que tomar puntos de referencia para saber que es un 1, un 3, un 7, una S, una M… o, cualquier nombre que el equipo quiera darle a este etiquetado.

La clave está antes de empezar: tomar de referencia de qué significa un valor para todo el equipo. Por ejemplo: Un formulario de autenticación en la UI es un 1, una api rest sin lógica de negocio con persistencia en base de datos un 3, y una tarea que va desde la UI hasta la BD, con documentación incluida y test de regresión, es un 7.
Cuanto más reales sean los escenarios, mejor. El consejo es ir a tareas específicas, que ya hayan sido desarrolladas y terminadas en el proyecto.

Una vez tienes estas etiquetas definidas para el equipo, es importante revisitarlas durante el tiempo para ajustarlas con el paso de los meses. La complejidad de la aplicación puede aumentar, la metodología de trabajo puede cambiar, los requisitos han variado con el tiempo, la deuda técnica no se ha resuelto…

Además es muy importante recalcar qué es una etiqueta del equipo, para el equipo. En el momento en que cambia cualquier persona del mismo, se debe volver a redefinir este etiquetado.

Tener recogidas estas referencias en un documento, es muy buena idea, ya que permite revisitarlas y llevar un seguimiento de ellas, y los cambios que se realizan.

No es aconsejable que existan más de 3 etiquetas.

Consenso de grupo

Hasta ahora hemos hablado del etiquetado, de la estimación y de los valores que se pueden dar a nivel individual. Pero al final se trata de un trabajo de equipo. Muchas veces, se da más peso a la opinión de un experto que a la del grupo en general.

Es cierto que el expertise es un punto de referencia, pero no una verdad absoluta. Hay un experimento realizado por Francis Galton, que refleja este escenario de forma perfecta.

En un pueblo, se crearon dos grupos: el primero, conformado única y exclusivamente por el carnicero del mismo, y el segundo grupo, conformado por el resto del pueblo. Cuando se pedía que se dijese a ojo el peso de una pieza de carne, ¿Qué grupo crees que daba el valor más acertado?

Para sorpresa de los asistentes, y aunque las respuestas del carnicero no estaban alejadas de la realidad, las respuestas del pueblo, eran mucho más precisas. Esto se debe al factor colectivo, la puesta en común, el debate y el raciocinio. El carnicero se basaba en su experiencia, pero no tenía capacidad de contraste o debate, mientras que el segundo grupo sí.

Es cierto que aquí entran en juego factores externos, como puede ser el denominado “tonto del pueblo”, el cual introduce en el grupo valores de desviación. Sin embargo, recordemos que en nuestro día a día, ésto se trata de una estimación, y no, de un papel grabado a fuego que no admite ningún tipo de desviación.

Conclusión

En primer lugar, agradecer a Fernando Bogas Pomares su participación en el Agile Open Spain, y que transmitiese su visión como Agile Coach con el resto de asistentes. Gracias a su ejemplificación en el taller, hemos sido capaces de definir unas reglas básicas de etiquetado de tareas, consensuadas por el equipo y actualizadas en el tiempo, que nos ayudan a ser más precisos en nuestro día a día.

Por otra parte, el cómo mantener debate, y llegar a un consenso sin tomar como verdad absoluta la opinión de los expertos en un área, nos ayuda a que las personas se sientan más involucradas en los procesos diarios.