Sobre estimar y por qué hacerlo en horas es una mala idea.

La respuesta rápida, sin entrar en matices, es muy simple: Nos conduce a tomar decisiones basadas en una mentira.

Alguien siempre dirá que necesitamos saber cómo planificar cada acción necesaria para llevar a cabo el proyecto en un plazo establecido; hay que marcar unos tiempos para valorar costes, y hay que poder hacer seguimiento de algún modo de los avances realizados. Sí, cierto, pero como tomemos esto de forma dogmática, queriendo tenerlo todo claro desde el principio, al final veremos que la realidad no coincidía con ese plan tan perfecto y realmente creíamos saber pero no sabíamos nada.

Aplicar agilidad responde a esa preocupación. Pero he visto un video resumen de SCRUM, que dura 10 minutos, que habla de estimar en horas. Quien haya leído el libro de Jeff Sutherland "Scrum: El nuevo y revolucionario modelo organizativo que cambiará tu vida", creador de SCRUM, se sorprenderá de que en el libro Jeff es muy duro con la estimación en horas, pero en algunos sitios aún se habla de estimar en horas.

Empecemos asumiendo que hemos decidido estimar en horas, así que, vamos a coger el listado de requisitos y a meter horas de cosas que no tenemos ni por qué conocer. Apliquemos entonces esa famosa formula matemática para estimar en horas. Vaya, parece que nadie la conoce. Ya tenemos aquí el primer problema. No hay una forma matemática de estimar, toda estimación está siempre basada en la perspectiva del que estima, y todos estamos llenos de sesgos que no nos dejan decidir de forma clara y fehaciente.

"What You See Is All There Is".

En "Pensar rápido, pensar despacio", Daniel Kahneman, habla de un sesgo cognitivo al que se refiere con el acrónimo WYSIATI ("What You See Is All There Is"). Este sesgo nos ayuda a tomar rápidas decisiones, sin que nuestro sistema lógico y lento interfiera, creando un entorno coherente eliminando la incertidumbre. Nos ayuda a "saltar a las conclusiones sobre la base de una evidencia limitada" y es la esencia del pensamiento intuitivo que utilizamos a diario. De las misma forma que este sesgo nos ayuda en nuestra vida diaria también nos puede jugar malas pasadas. A la hora de pensar nuestro cerebro crea un marco coherente que nos genera seguridad, y aquí es dónde un exceso de confianza en WYSIATI nos puede hacer caer en el error de ignorar todo eso que no estamos viendo. Tener en cuenta posibilidades que desconocemos puede estropear nuestra perfecta historia donde todo está controlado, por lo que se ignoran. Así es como se toman muchas importantes decisiones que acaban en desastre.

Cuando nuestro conocimiento es escaso, y eso suele ocurrir siempre que se estima ya que aún no nos hemos metido en el fango, por decirlo vulgarmente, es más fácil crear una historia coherente en la que todo encaja. Se estima por debajo, muy por debajo, y cuando surgen los problemas que no conocíamos surge el desastre ya que hay que meterlo todo en un plan totalmente calculado dónde la novedad inesperada ya no encaja. WYSIATI nos la ha jugado. 

Por tanto, entendiendo qué es WYSIATI, a la hora de estimar ignoraremos todo aquello que no vemos creando una estimación basada en escasa información.

Vamos a pesar cuan complejas son las cosas.

Asignando un peso en complejidad para estimar, tirando de la secuencia de Fibonacci para evitar números cercanos, es más fácil tener en cuenta esa incertidumbre que si usásemos horas. Decir que una cosa tiene una complejidad de 5 y la siguiente de 8 siempre es más fácil que, incluso con horas, decir que tardaremos 5 horas u 8 horas. Un peso no implica tiempo per sé, sólo complejidad, pero una hora es unidad de tiempo por definición.

Entonces, para estimar en horas, debemos al menos saber qué estamos estimando. Cuanto mejor lo conozcamos mejor será esa estimación. Pero es imposible conocer todos los detalles, sobre todo si es algo en lo que no hemos trabajado, y muchos detalles de lo que sí hemos trabajado somos incapaces de contemplarlos mentalmente hasta que los tenemos delante una vez hemos retornado a ello. Cuando comenzamos a refrescar la memoria vemos todo más claro. De ahí que surjan herramientas como el cono de incertidumbre que nos viene a decir que cuando estimamos algo hay un margen de error que al principio es muy grande y se va reduciendo, junto a la incertidumbre, según avanzamos en el proyecto acercándonos al final. El problema de esto es que, aún siendo conscientes de dicha incertidumbre, estipular horas desde el comienzo hace que sea muy tentador pensar que estamos hablando de un plazo que se cumplirá, sobre todo si es alguien no técnico quien lo valora. Un peso en complejidad, que puede modificarse con el descenso de la incertidumbre, siempre es más útil y fácil de manejar.

Y si seguimos pensando en horas tendremos muchas preguntas que hacernos.

¿De qué sirve una estimación en horas si el que estima no ha trabajado en lo estimado? De nada ya que desconoce totalmente cómo está hecho y el porqué de todos los detalles.

¿De qué sirve una estimación en horas si el que ha estimado sabe el cómo y el porqué pero no va a trabajar en ello? Esa estimación, basada en conocimientos personales, queda en nada porque quien ejecutará partirá desde otro punto de salida y una perspectiva de la situación totalmente distinta.

Entonces, ¿quien debe estimar cada nuevo requisito?

Estas preguntas son básicas para empezar a ver por qué usar horas no es una buena idea, sobre todo si la estimación la hace una única persona (algo habitual en proyectos tradicionales). Y aquí la agilidad nos aclara que debe estimar todo el equipo que va a trabajar en ello. El equipo, al estimar, tendrá más facilidad manejando pesos de complejidad que horas.

Otros sesgos que nos harán entender la complejidad de estimar que nos muestra Daniel Kahneman en su libro son: Efecto ancla y la falacia de la planificación.

Efecto ancla.

Se produce cuando las personas consideran un valor particular para una cantidad desconocida antes de estimar esa misma cantidad. Al final, debido a este sesgo, las estimaciones siempre están cerca de ese número que se ha considerado previamente, de ahí la imagen de un ancla. El efecto ancla está muy estudiado en psicología experimental y es aceptado de forma general.

Un ejemplo lo tendríamos cuando, para un requisito determinado, nos dicen: "Queremos entregarlo en 20 días, ¿cuando estará listo?". Al final la estimación rondará los 20 días, siendo unos 15 si lo consideramos sencillo y siendo 25 si lo consideramos difícil. Si nos hubieran dicho 30 días habríamos estimado en torno a los 30 días. Nos vemos condicionados por un valor que no debería haberse considerado para hacer la estimación.

Otro ejemplo de efecto ancla lo podemos tener en el tiempo que sabemos que tenemos y que nos va quedando según vamos estimando distintos requisitos. Si tenemos 1 mes para 5 requisitos, y ya hemos estimado 4, conocemos el tiempo que falta para llegar a un mes, por lo que el quinto requisito estará anclado a ese valor de tiempo pendiente de estimar. Al final ajustaremos el tiempo estimado de trabajo al tiempo disponible dentro del plazo determinado. Si el último requisito lo hubiéramos estimado primero el ancla habría sido más flojo, por lo que la estimación estaría menos condicionada al tener aún todo el tiempo disponible, pero aún así el mes de plazo seguiría ejerciendo de ancla ya que sabemos que tenemos otras cosas pendientes de estimar y no debemos pasarnos.

La falacia de la planificación.

Cuando se aborda un proyecto a largo o medio plazo se da una estimación en base al conocimiento interno que se tiene del proyecto en ese momento (WYSIATI  ataca de nuevo). Es lo que Kahneman llama la visión desde dentro, y en ella estaríamos atrapados ignorando los plazos confirmados por otros equipos en otros proyectos similares. Es la tasa base de la que deberíamos partir, pero al final siempre es ignorada y no se tiene en cuenta; pensamos que nosotros lo haremos mejor o no tendremos tantos problemas.

Estas previsiones iniciales, si no se tiene en cuenta la tasa base de la visión desde fuera, encierran una falacia de planificación: Las estimaciones están siempre más cerca del mejor de los casos que de una estimación realista.

Esa estimación inicial se lleva a cabo con el conocimiento de partida cuando todo es más sencillo y aún no han surgido problemas internos y externos.

Esto, en un proyecto estimado desde el primer momento, o incluso a 3 meses vistos para una nueva release, siempre acaba mal. ¿No estarían mejor iteraciones de trabajo cortas en las que estimamos una y otra vez con el conocimiento adquirido en cada iteración? Con agilidad volvemos a eliminar incertidumbre y complejidad.

¿Y cómo realizamos la estimación sea en horas o pesos?

Si nos vamos al libro The Clean Coder (libro imprescindible, por cierto) de Robert C. Martin vemos que hay un capitulo dedicado a estimar en el cual habla sobre:

- La ley de los grandes números. Cuanto mayor sea lo que hay que estimar peor se estimará.

- La interpretación de qué es una estimación es distinta para la gente de negocio que para los desarrolladores. Para la gente de negocio es una fecha a cumplir. Para los desarrolladores es una idea aproximada de lo que se va a tardar.

- Siempre hay que dar en la estimación un margen de error. Aquí Martin mete una formula en la que incluye la estimación que creemos es la más optimista, la que creemos más adecuada, y la que creemos es la más pesimista. Luego con la más optimista y más pesimista obtiene la desviación estandar para dar el margen de error.

- Advierte que un buen profesional nunca debe dar una estimación sin margen de error. Si un desarrollo va a tardar 4 días (si medimos tiempo y no peso) en realidad puede tardar 2, 4 o 6 si el margen de error son 2 días. Eso siempre que la creencia en las estimaciones aplicadas sea cierta; raramente lo es.

- Habla de utilizar la secuencia de Fibonnaci (horas, dias, puntos, ...).

- Habla del 'Planning Poker' y otras formas de estimación.

En horas todo es más complicado.

Algunos de estos puntos nos sonarán ya conocidos del libro de SCRUM (y del mundo ágil), ya que SCRUM no es más que un compendio de buenas prácticas con su propia esencia. Por ejemplo hacer planning poker viene de Extreme Programming pero también es utilizado en SCRUM (no es obligatorio).

La hora trabajo como unidad.

Y si aún seguimos pensando en horas podemos tratar de cuantificar qué es una hora. Aquí hablamos de la "Hora Trabajo" y no de 60 minutos.

Nos hacen falta ciertas preguntas.

¿Qué es una hora de trabajo cuando hablamos de trabajo no industrial? ¿Una hora equivale siempre a una hora? ¿Es lo mismo una hora de un lunes que de un viernes? ¿Es lo mismo una hora por la mañana que por la tarde? ¿Es lo mismo una hora en una tarea de alguien que haya trabajado en ello que de alguien que lo ve por primera vez? ¿Es lo mismo una hora de un novato que de alguien con mucha experiencia? ¿Es lo mismo una hora de trabajo tras una mala noche que tras una noche reparadora? ¿Es lo mismo una hora de trabajo el día que estamos preocupados por algo personal que el día que estamos felices? La respuesta a todas estas preguntas, y muchas similares que se pueden hacer, es NO: una hora no es comparable a otra hora. ¿Por qué entonces queremos saber cuantas horas se tardará si estamos estimando en una magnitud ("la hora trabajo") que dependiendo del momento tendrá un valor diferente? Un peso en complejidad vuelve a ser más apropiado.

Por eso no es posible afirmar que en X horas de trabajo estimado podemos aportar X horas de un desarrollador. Si algo necesita 30 horas no podemos aseverar que esas horas se pueden cubrir con 30 horas de alguien si una hora nunca es equivalente a otra. Asignar horas antes que elegir quien y cuando lo hará es muy típico, y de ahí que nunca sea buena idea.

Y cuando acabamos algo estimado en horas, ¿qué conclusión sacamos?

Y ya, si hemos estimado en horas, una vez finalizado el trabajo, tenemos las siguientes situaciones:

1. Al final se necesitaba menos tiempo en horas del estimado. Aquí entra en juego la ley de Parkinson: "El trabajo se expande hasta llenar el tiempo disponible para que se termine". Así que si tenemos 4 días, y podríamos tardar 2, tardaremos 4 días en pos de la perfección y no de algo suficientemente bueno. La búsqueda de la perfección carece de sentido cuando el esfuerzo realizado apenas aporta valor respecto a algo suficiente bueno pero, si tenemos el tiempo, ¿por qué no aprovecharlo?
2. El tiempo de trabajo coincide con el tiempo estimado. En la mayor parte de los casos esto será casualidad y sólo será cierto para pequeñas estimaciones de algo que tenemos muy fresco. Al ser casualidad podremos caer en el error de pensar que sí sabemos estimar en horas, cuando no sabemos, y decidir en base a todas esas estimaciones que no van a ser ciertas.
3. Al final se necesita mucho más tiempo que el estimado, lo que nos lleva a retrasos no esperados o a acabar de forma precipitada con la merma de calidad correspondiente y la deuda técnica introducida en el desarrollo, lo que nos hará ir más despacio en el futuro. 

Todo esto son grados de complejidad con los que hay que tratar. Con agilidad, y sobre todo si decidimos estimar en peso de complejidad, podemos minimizar el problema asociado a toda esa incertidumbre que no nos permite saber cuando acabaremos.

Pero, una última pregunta pendiente.

Si el cliente me pide una estimación, y no estimo en horas, ¿cuando le digo que lo tendrá?

Como hemos medido la velocidad del equipo sabiendo cuanto peso de complejidad es capaz de resolver por sprint podemos saber cuantos sprints estimados necesitaremos para terminarlo, y un sprint sí es convertible en tiempo. Si necesitamos 3 sprints de 2 semanas cada uno tardaremos 6 semanas, pero cada 2 semanas podremos tener completada una pequeña parte con valor potencialmente entregable (si queremos entregarlo). 

Lo bueno de medir en peso es que, según el equipo mejora, podemos ir aumentando el peso en complejidad resuelto por sprint. Si en cada sprint el equipo completa 100 en peso, luego puede resolver 120, luego 140, y así estabilizarse en torno a una nueva velocidad, todo gracias al mejor conocimiento del proyecto y la mejoría de trabajo lograda. Por tanto, si volvemos al ejemplo anterior, en un nuevo requisito similar ya no necesitaremos 3 sprints, con 2 será suficiente, por lo que se puede entregar antes. Y no hemos necesitado re-estimar modificando el peso en complejidad, simplemente somos capaces de hacer mejor trabajo y ser más resolutivos. Eso no quiere decir que al principio de cada sprint no se puedan modificar pesos estimados gracias a nuevo conocimiento, aquí hablamos de medir la velocidad del equipo y que eso por sí solo nos permita crear valor de forma más rápida.

Si estimamos en horas en vez de en peso la cosa cambia. Si estimamos en 6 semanas, por mucho que mejore el equipo, 6 semanas son 6 semanas. Tendríamos que decir  que son 6 semanas estimadas pero que las vamos a meter en 4 semanas, y eso mentalmente es algo que no somos capaces de manejar. Entonces tendríamos que re-estimar muchas issues en tiempo, por lo que volvemos a los problemas iniciales y perdemos la capacidad de medir la velocidad del equipo. Podemos usar horas como si no fuesen horas, pero estaríamos usando una medida que cada participante en el proyecto interpretaría de una forma diferente.