Estimación de tareas ¿si o no?

En ocasiones he visto artículos donde se relaciona la práctica de la estimación de tareas con la madurez del equipo. Vamos a analizar si esta relación tiene sentido con opiniones reales de personas en equipos que lo hacen y que no.

¿Es viable poner en duda la madurez del equipo por estimar las tareas que van a realizar? He leído en alguna ocasión que incluso se ponía en duda la madurez del Coach del equipo. Sobretodo por usarlos como métrica. Es decir, se interpretaba que su uso no debería darse en equipos muy maduros. Y de ser así, entonces quizá el Coach del equipo era el que tenía que crecer profesionalmente.

Para los que no estáis familiarizados con los la estimación de tareas, es una forma de valorar el esfuerzo, incertidumbre y complejidad de cualquier tipo de tarea a la que se enfrente el equipo en lugar de prever las horas que se van a dedicar a ella, de manera que podamos tener una velocidad de trabajo del equipo. Normalmente se usan lo que se llaman «Puntos de Historia» que siguen la serie de Fibonacci, aunque también pueden usarse otros medios como tallas de camiseta, tamaño de animales…

Esta deducción me hizo pensar si yo estaba de acuerdo o no con esa reflexión. Y al final me dí cuenta que lo mío podía ser sólo una opinión, que lo mejor era preguntar a los equipos que estimaban tareas y a los que no, para saber qué beneficios tenían o si realmente aquellos que lo hacían desde hacía tiempo, lo hacían por mera rutina. Y digo mera rutina porque estoy de acuerdo en que cómo métrica no aportan valor cuando los equipos aprender que la entrega de valor no está relacionada a la cantidad de estimación sumada de las tareas que haces en un determinado tiempo.

Las opiniones sobre el uso de la estimación de tareas

Equipos que la usan

^{Creo que estimar tareas fue uno de los aspectos clave para que el equipo cambiara de mentalidad y nos permitiera avanzar en el desarrollo de nuestra madurez. La estimación consiguió que el equipo olvidara las horas y las valoraciones de esfuerzo por tiempo y pasáramos a pensar en complejidad. Todos se sienten más implicados, se liberan de la presión de las horas, permite un margen de desviación por el que unas tareas se ven compensadas con otras, nos permite saber si una tarea es demasiado compleja para abordarla en un sprint…}

Product owner

^{Dejar de medir en horas y empezar a hacerlo en puntos de historia supone un cambio de mentalidad, en el que el acompañamiento del Coach es clave. Una vez te acostumbras, creo que el equipo se quita presión respecto a los tiempos de entrega y lo que tarda un miembro u otro en hacer una misma tarea. Personalmente, aunque haya gente que le cuesta más este proceso al ser una medición un poco abstracta, me parece una estimación mucho más acertada.}

Desarrollador C#

^{Desde mi punto de vista es útil por varios motivos; te ayuda a controlar la cantidad de tareas que asumes por sprint una vez sabes la velocidad de desarrollo. Pero por otro lado también sirve cuando puntúas para ver si el resto del equipo ve la misma complejidad o no que tu.}

Desarrolador Java

^{Tengo que reconocer que trabajar con puntos de historia al principio rompe los esquemas. Estamos acostumbrados a trabajar con el concepto del tiempo, que es lo que nos suelen pedir los responsables y de pronto tienes que darle una vuelta mental y cambiar “el idioma”. Podemos trabajar igualmente en un marco de tiempo, pero ya estamos dejando de hacerlo de forma directa. Una vez saltada la primera barrera te das cuenta de que es más cómodo para el equipo el ser consciente del esfuerzo que conlleva cada tarea. Como nota final, pero no menos importante, hacer hincapié en que tener un buen Coach que te acompañe en la transición y te ayude con las dudas durante el proceso de re-aprendizaje es esencial.}

Desarrolladora Cobol

^{Me da una guía de lo que pueda asumir un equipo en futuros sprints. Si necesito saber el % de avance de una funcionalidad, o para trabajar con las versiones de lanzamiento, me va mejor por puntos que por número de tareas, pues nos es más complicado detectar tareas que son muy grandes si no usamos un tipo de estimación como este.}

Product Owner

Equipos que NO la usan

^{Nos gusta usarlos sólo para saber si vamos todos alineados. Además, esa alineación ayuda a compartir conocimiento. Tenemos como norma no crear tareas que puedan costar más de un cierto esfuerzo, así que más o menos todas tienen el mismo tamaño y no lo informamos. Trabajamos en Kanban y el tamaño unificado nos ayuda a mantener el flujo de entrega, que es lo que medimos.}

Desarrollador Java

^{No usamos ningún tipo de estimación, simplemente vamos creando tareas y realizándolas en modo Kanban. Controlamos mucho el hecho de limitar el trabajo en progreso y procuramos hacer mucho pull para mantener un flujo constante. En el equipo somos pocos y nos entendemos bien a la hora de dividir tareas para que no sean muy grandes.}

Desarrollador Java

Conclusiones

Desafortunadamente no he encontrado más opiniones de equipo que no usen estimación por puntos de historia, u otros métodos de estimación.

Con estos testigos me atrevería a decir que no pienso que unos sean más o menos maduros que otros. Cada equipo tiene que trabajar como mejor le vaya para medir su velocidad y ver dónde pueden mejorar.

Dejemos de valorar la madurez de los equipos por cómo trabajan y cómo miden sus cosas. Empecemos a medir el valor que entregan y cómo llevan su auto-crítica para mejorar constantemente. Para mí un equipo es maduro cuando:

sabe porqué entrega lo que está entregando y qué implicación comporta al negocio
recapacita para mejorar
usa el feedback para aprender
hay confianza entre ellos y con su relación exterior
es completamente transparente
sabe que cualquier tipo de medición es para prever de forma empírica, no para compararse con nadie.

¿Cuál es vuestra opinión al respecto? Sea la que sea será bienvenida, podéis dejarla como comentario a continuación.

5 (2 votos)