¿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 esa reunión por desconocimiento?
Esto ocurre más a menudo de lo que parece. Cuando estimamos nos enfrentamos a un gran dilema: un compromiso rodeado de incertidumbre, que no busca fiscalizar, pero sí dar visibilidad del esfuerzo que puede conllevar una tarea para facilitar una buena planificación de producto.
Las estimaciones dan una sensación de falso control. Etiquetar una tarea transmite seguridad y compromiso, pero en realidad se trata de una falacia. Una estimación no es una fecha, sino un indicador con posibilidad de cambio. Esa sensación de seguridad se desdibuja cuanto menos precisa es la estimación.
Ahora bien, la información que se obtiene en una sesión de estimación es muy importante, aunque no sea una verdad absoluta. La cuestión es: ¿cómo la llevamos a cabo?
Tomar puntos de referencia
- “Esto es un uno”
- “Pues para mí es cinco”
Es muy común encontrarnos con esta situación en sesiones de estimación. ¿Cuál es el problema? Nuevamente, los sesgos. En el Agile Open Spain de 2022, Fernando Bogas Pomares propuso el siguiente ejercicio:
Sin buscar en Internet, dime, bajo tu criterio: ¿cuánto mide la Torre Eiffel?
Probablemente el valor que respondas pueda estar más cerca o más lejos de la realidad. Sin embargo, cuando se pone en común con el resto de participantes, se ve una gran disparidad en los resultados.
Ahora bien, si comparamos una foto de la Torre Eiffel y una foto de la Gran Pirámide de Guiza, donde podemos tener un punto de referencia, y decimos que la pirámide mide 139m, ¿cuánto dirías que mide ahora la Torre Eiffel?
Probablemente ahora seamos capaces de dar un valor mucho más aproximado, porque ya tenemos un punto de referencia con el que comparar.
¿Y si añadimos más información a la ecuación? Podemos compararla también con el Empire State Building, que mide 449m:
Con esos puntos de referencia, seguro que ahora resulta más fácil estimar con mayor precisión la altura de la Torre Eiffel.
💡 Como nota adicional, la Torre Eiffel mide 324m. ¿Te acercaste?
La clave está en tener puntos de referencia. Cuando estimamos, el equipo tiene que saber qué es un 1, un 3, un 7, una S o una M, o cualquier otra etiqueta que el equipo quiera utilizar.
La clave está antes de empezar: tomar como referencia 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 es un 3, y una tarea que va desde la UI hasta la base de datos, 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 definidas estas etiquetas, es importante revisitarlas con 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 pueden variar o la deuda técnica puede no haberse resuelto.
También es importante recordar que esta es una etiqueta del equipo, para el equipo. En el momento en que cambia cualquier persona del mismo, conviene volver a redefinir el etiquetado.
Tener recogidas estas referencias en un documento es una gran idea, porque permite revisitarlas y hacer seguimiento de cómo evolucionan.
⚠️ 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 estamos hablando de trabajo en equipo. Muchas veces se da más peso a la opinión de una persona experta 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 solo por el carnicero, y el segundo, por el resto del pueblo. Cuando se pidió estimar a ojo el peso de una pieza de carne, ¿qué grupo crees que dio el valor más acertado?
Para sorpresa de muchas personas, aunque las respuestas del carnicero no estaban lejos 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 el denominado “tonto del pueblo”, que introduce valores desviados. Sin embargo, recordemos que en nuestro día a día esto sigue siendo una estimación y no un valor grabado a fuego sin posibilidad de desviación.
Conclusión
En primer lugar, gracias a Fernando Bogas Pomares por su participación en Agile Open Spain y por compartir su visión como Agile Coach con el resto de asistentes. Gracias a la ejemplificación del taller, hemos sido capaces de definir unas reglas básicas de etiquetado de tareas, consensuadas por el equipo y actualizadas en el tiempo, que ayudan a ser más precisos en el día a día.
Por otra parte, el modo de mantener el debate y llegar a un consenso sin tomar como verdad absoluta la opinión de las personas expertas en un área ayuda a que todas las personas se sientan más involucradas en los procesos diarios.