El concepto “estimar” es de los que más controversia crea desde que Agile se ha puesto de moda. Culturas como el #Noestimates están apareciendo y generando incondicionales y detractores. La estimación en situaciones donde los requisitos no paran de cambiar, no conocemos todo lo que hay que hacer y siempre acaban por aparecer cosas que querremos hacer a última hora, no tiene mucho sentido. Aún así, animados por la cultura de la planificación nos animamos a ellos. Recientemente, he vuelto a vivir una situación que he vivido muchas veces y que me parece bastante poco útil. Típico proyecto que tiene problemas, y, para resolverlo, lo primero que hacemos es parar al equipo a estimar todo lo que queda. Esta estimación, se hace restando al equipo tiempo de trabajar, que es lo que realmente aporta valor. Esta situación, nos lleva a la siguiente paradoja: vamos mal, y paramos para estimar y entonces iremos peor porque el tiempo en estimar nos resta opciones de “llegar a la fecha”.
Recientemente, estuve en la Kanban Week, y pude estudiar otra vez la historia del primer equipo que aplicó Kanban en el desarrollo software. Una curiosidad que no conocía, eran las tareas que este equipo abordaba, que eran de diferente índole. Entre ellas fijaron dos tipos al que añadieron un tercero: desarrollos, incidencias y estimaciones.
¿Estimaciones? Hay equipos que se les pide muchísimas estimaciones, entre otras cosas, para decidir si queremos o no un desarrollo concreto. Esas estimaciones llevan tiempo, y después, tenemos la sensación de que el equipo es “vago” porque no han sacado mucho trabajo. Por ejemplo, un equipo termina 20 incidencias, 10 desarrollos y 44 estimaciones (de cosas que muchas de ellas no se desarrollan). Para la organización, el equipo solo ha hecho 30 cosas, cuando realmente ha hecho 44 estimaciones que le llevaron mucho tiempo.
El hecho de cuantizar las estimaciones, ayuda mucho a tener una palanca que te permita mover cosas. Es una manera de decir: “este tiempo no es productivo, lo haremos si queréis, pero no aporta valor real a la organización”. De hecho, este equipo consiguió eliminar esas estimaciones y sustituirlo por mediciones empíricas en base a la capacidad del equipo de entregar.
Otra situación típica de estimaciones es cuando, un cliente te contrata para una entrega-en-fecha, y la fecha es la que es, pero aún así, te piden estimación. ¿Para qué queremos una estimación si este desarrollo tiene que estar en la fecha ya cerrada? Pongámonos a trabajar, y midamos nuestra capacidad de entregar (aunque lo ideal es la capacidad de generar valor).
Todo esto, me ha llevado a cambiar mi visión sobre las estimaciones. Los que han trabajado conmigo, saben que me gusta mucho la estimación por puntos de historia. Sin embargo, intento trabajar sin estimaciones con los equipos, al menos es mi propuesta con ellos. Prefiero que hablemos de cómo podemos abordar el problema que tenemos delante, de cómo organizarnos o ser efectivos, que de dar unos números que ninguno de nosotros nos creemos.
Tabla de contenido
Entradas relacionadas
Los pilares de Scrum : infografía4.7 (12)
Comentarios recientes