[Estimaciones Agile & No-agile] Todo lo que debes saber sobre estimaciones ágiles y no-agiles, su implementación, ténicas y herramientas

Una estimación es la acción de “proporcionar un valor cercano” que represente el esfuerzo que requerirá realizar el alcance de un trabajo.

Con frecuencia proporcionar una estimación resulta desafiante para personas y equipos con bajo nivel de madurez técnico, metodológico o de negocio. Por lo general la duda común es ¿qué debo tener en cuenta?, acá te cuento qué deberías tener en cuenta:

Volumen (volume): por supuesto el primer factor a considerar para determinar el nivel de esfuerzo de un trabajo por hacer es en sí mismo la cantidad requerida de hacer.

Complejidad (complexity): se relaciona con el nivel de dificultad que tiene realizar el trabajo acordado, es un factor que junto con el volumen permite decantar entre las opciones a estimar cual requerirá más esfuerzo.

Conocimiento (knowledge): realizar un trabajo de alto volumen y alta complejidad puede verse influido en su estimación el nivel de madurez de quienes realizaran el trabajo en cuanto al conocimiento que tienen técnicamente y del negocio involucrado, si el conocimiento es alto entonces la estimación tenderá a ser menor, contrario a si se cuenta con un nivel de conocimiento bajo.

Incertidumbre (uncertainty): se relaciona con las indefiniciones conocidad presentes y con la sospecha que aún podrían existir algunas consideraciones futuras que no se tuvieron presentes.

La combinación de estos cuatro factores te permitirán tener una mejor idea del alcance del trabajo a realizar, esto es lo que conocemos como “claridad” sobre el valor e incremento esperado, el cual es altamente recomendado que se obtenga en sesiones de refinamiento efectivas.

De cualquier modo, aun cuando realices las mejores sesiones de refinamiento ten presente que una estimación es la acción de “proporcionar un valor cercano” que represente el esfuerzo que requerirá realizar el alcance de un trabajo. El proceso no se llama “exactimación”, partimos del hecho que nunca será exacto pero sí podemos lograr que sea muy cercano.

¿Qué hace una estimación ágil distinta de una estimación predictiva?

Lo que hace diferente una estimación ágil de una estimación para proyectos o productos de naturaleza predictiva es que para las predictivas se suele contar con el “criterio de expertos”, personas que han realizado las actividades tantas veces que pueden estimar con un mayor nivel de exactitud el valor real, distinto a una estimación ágil, donde no se cuentan con expertos sino con personas que empíricamente han ido aprendiendo a lo largo del tiempo sobre el producto, el negocio y los usuarios.

La naturaleza compleja del trabajo a estimar hace que una estimación ágil pueda reconocer que el conocimiento del equipo es diverso y usualmente no uniforme, que por la naturaleza del producto que se está construyendo no haya un precedente al cual seguir como guia y, que el rumbo del producto es altamente influido por los usuarios, sus gustos, percepciones, cultura, geofría, creencias y tendencias.

De cualquier modo, sea que uses técnicas de estimaciones predictivas o ágiles, siempre serán un “valor cercano” con mayor o menor grado de fiabilidad, pero al final susceptible de cambiar en el tiempo debido a diversos factores.

¿Qué se requiere para empezar a usar estimaciones en mi equipo?

Para empezar a usar estimaciones variará dependiendo del tipo de poyecto, si es un proyecto predictivo el camino es más claro justamente por ser un proceso establecido en el PMBOK, en cambio si es un proyecto que trabaja con agilidad, puede que se requiera inicialmente voluntad, apertura y resiliencia.

Pasar de no usar estimaciones a querer implementarlas es un desafío, genera incertidumbre, ansiedad y desconfianza. Al rededor del tema hay muchas frustaciones y malas experiencias previas, yo te comparto los que considero son los mejores pasos a seguir si quieres implementar estimaciones.

Ofrece un entrenamiento sobre estimaciones, los diferentes tipos y técnicas, así como aquellas que mejor se adaptan a tu realidad.
Define la técnica de estimación que el equipo empleará para realizar sus estimaciones y profundiza sobre los aspectos a tener en cuenta.
Define la herramienta o medio para realizar la estimación y cómo es el proceso a seguir.
Asegurate de crear el entorno seguro que las personas que estimarán necesitan para no ser influidos o juzgados por sus valoraciones.
La práctica hace al maestro, es cuestión de tiempo para que cada vez fluya y resulte mejor.

Unidades de Estimación

El cono de la incertidumbre como concepto ilustra cómo a partir del nivel de claridad sobre el trabajo a realizar es posible hacer uso de una unidad de estimación o la otra. Como se puede apreciar en la imagen, a medida que el nivel de incertidumbre es mayor, se recomienda hacer uso de unidades menos precisas mientras que a medida que el nivel de incertidumbre disminuye (claridad aumenta), se puede hacer uso de unidades númericas.

Imagen 1. Cono de la Incertidumbre

T-shirt Size: Es una unidad de medida inspirada en las tallas de camisetas, esta unidadad es usada para la estimación de porciones grandes de trabajo que requieren de sesiones de refinamiento como las Epicas.
Fibonacci: Es una unidad inspirada en la famosa serie de fibonacci, esta unidad es usada para la estimación de porciones más pequeñas de trabajo que representan un incremento y que requieren sesiones de finamiento como las User Stories.
Horas: Es la unidad de medida más común y ampliamente usada en las técnicas de estimación predictivas, es usada cuando la proporción de trabajo es tan pequeña y clara que es posible proporcionar un “valor cercano” muy exacto.

Técnicas de estimación predictiva

Las técnicas de estimación predictiva son muy populares para proyectos que siguen los lineamientos del PMI, debido a que suelen aportar un alto nivel de exactitud a costa de una inversión significativa de tiempo definiendo cada detalle para que expertos puedan proporcionar su estimación. Son técnicas que no funcionarán muy bien si no tienes las personas correctas. Su nivel preferido de estimación son las “tareas/actividades” en horas.

Análoga: es la técnica más rápida de todas las predictivas, consiste en aprovechar las lecciones aprendidas de proyectos similares anteriores para estimar las diferentes actividades de un proyecto. Si bien es la técnica más rápida de todas es la menos precisa, debido a que no considera las condiciones en la que se desarrollaron los proyectos pasados vs las condiciones actuales.

Paramétrica: es una técnica no tan rápida como la análoga, sin embargo, permite obtener un gran grado de precisión en aquellas actividades del proyecto que puedan ser parametizables, es decir; se requiere que la actividad a estimar tenga un factor que pueda ser multiplicado para conocer su valor final.

P.E.R.T: esta técnica también conocida como la estimación de tres puntos, es una técnica no tan rápida pero con un alto nivel de precisión debido a que es requisito que participen más de un experto en la actividad especifica a estimar. Es recomendado que sea tres estimadores por cada actividad, de modo que el promedio de los expertos sea el valor final a considerar.

Top-Down: esta técnica es mayormente útil cuando tenemos una limitación definida sobre el global del proyecto. Básicamente se busca repartir el gran total en pequeñas porciones de trabajo. En mi opinión no es muy acertada pero si que es cierto que muchos hemos estado expuertos a proyectos donde nos dan una fecha fija de entrega y apartir de ahí toca planificar las porciones más pequeñas de trabajo.

Bottom-Up: esta técnica en esencia es opuesta a la Top-Down, se estiman las porciones pequeñas de trabajo y se suman sus estimaciones hacia arriba, logran al final tener el resultado final de duración y costo de un proyecto. Es una técnica muy acertada dependiendo de las técnicas que hayan sido utilizadas para estimar individualmente cada porción de trabajo.

Técnicas de estimación relativa

Las técnicas de estimación relativas reciben su nombre porque a diferencia de las predictivas no se requieren de expertos sino de personas que puedan relacionar el nivel de esfuerzo requerido en una porción de trabajo vs otra porción que previamente hayan realizado y la utilicen somo referencia para establecer si es igual, menor o mayor en cuanto a nivel de esfuerzo. Son técnicas altamente dependientes del conocimiento empírico.

Planning Poker: mas que una técnia me parece una dinámica, sin embargo, es la más popular dentro de los equipos ágiles que usan Scrum como su marco de trabajo. La técnica se basa en el concepto de estimar el esfuerzo de un trabajo en relación a una referencia, de ahí su nombre de “estimación relativa”. Se hace uso de la serie de fibonacci en cartas de poker para representar el esfuerzo requerido para cada porción de trabajo. Si quieres conocer más detalles sobre esta técnica te invito que visites este recurso.

Sin importar cual técnica emplees para realizar tu estimación relativa, mi mejor recomendación es que colabores con tu equipo para definir un pivote, es decir; una porción de trabajo de referencia que sirva para mitigar la disparidad de percerciones de los estimadores. En términos generales un buen pivote debería:

Ser una porción de trabajo ya trabajada y terminada
Ser una porción de trabajo lo más transversal a los skills del equipo
Ser claro y entendido por todos los estimadores

En algunos casos recomiendo emplear más de un pivote, los detalles de esto los compartiré en un blog futuro, de momento te recomiendo que si optas por tener más de un pivote trates que adicional a los items anteriores también cumpla la condición que cada uno tenga tamaño distinto entre sí.

Herramientas colaborativas que podrías usar

Sobre este tópico pueden haber opiniones divididas, en mi experiencia cualquier herramienta concurrente puede ser adaptada para tener una dinámica colaborativa, por supuesto hay algunas herramientas que ya están listas para empezar a usar, yo te comparto algunas que podrías usar o adaptar con poco esfuerzo para llevar adelante tu dinámica de estimación.

¿Puede una estimación cambiar su valor?

Si, como se mecionó anteriormente una estimación busca proporcionar un “valor cercano”, no uno exacto. Esto permite entonces que al momento de empezar a realizar un trabajo con los nuevos hallazgos se pueda poner en consideración un cambio del valor estimado inicialmente, tanto para arriba como para abajo.

Ya que hemos aclarado que una estimación puede ser actualizada, es importante comprender el impacto que tiene para un proyecto ágil y uno predictivo y, cuales son mi mejores recomendaciones de cómo gestionarlo para cada caso.

Para un proyecto ágil, el nivel de impacto que tiene un cambio en estimación puede resultar en que sea necesario renegociar el compromiso del sprint o iteración, tanto para añadir más trabajo por capacidad que haya quedado disponible al disminuir la valoración de un item de trabajo como remover items para que el trabajo con una nueva estimación mayor pueda ser trabajado y concluido.

Para un proyecto predictivo, el nivel de impacto de un cambio de estimación es mayor. Los proyectos predictivos buscan establecer un plan a detalle desde el inicio, esto es lo que conocemos como Upfront Planning. Este plan es altamente influido por la definición de las líneas bases del proyecto, en palabras sencillas, el alcance, costo y cronograma que debe seguir un proyecto de inicio a fin y, que será monitoreado y controlado a detalle para evitar cualquier desviación.

Comparativamente si es necesario actualizar una estimación de un proyecto ágil, bastará con comunicar a los stakeholders y reajustar el compromiso del sprint/ iteración en curso y los futuros, mientras que en un proyecto predictivo requerirá que se siga un proceso estricto de gestión de cambios donde puede que un cambio sea o no aprobado, y que esto se materialice entonces como un impacto a las métricas de performance del proyecto como CPI y SPI.

Mis recomendaciones sobre cambiar el valor de una estimación

Como lo prometido es deuda, te comparto algunas recomendaciones que te pueden ser útiles, pero ten presente el contexto en el que presento cada una para que puedas identificar si es el mismo que estás experimentando y así confirmar o descartar su utilidad en este momento.

Para proyectos ágiles:

Es importante tener presente que no siempre cuando una estimación es incrementada se debe dar por hecho que hay que mantener el item de trabajo y remover otros, en ocasiones los nuevos hallazgos pueden conducir a que se despriorice del sprint/ iteración para obtener mayor claridad antes de continuar. Por tanto, si los nuevos hallazgos consideras que requieren conversaciones adicionales para poder fluir en el desarrollo, es mejor postergar que incurrir en desperdicio y retrabajo.
Existiran ocasiones en que las dudas al momento de trabajar un item tengan origen en una pobre o nula definición sobre el hallazgo, no siempre asumas que frente a la duda el hallazgo debe ser incluido y trabajado, opta por tener clarificación de parte del Product Owner, Project Manager o Stakeholders y determinar qué tanto podría ser incluido y qué tanto podría ser postergado y trabajado en un item distinto, siempre teniendo en cuenta que debe haber valor en cada porción separada de cara a los usuarios.
Cuando concluyas que hay que definir items separados asegurate que el alcance a trabajar de cada item es un “software funcional”, y que no hay dependencia entre estos items para que el usuario pueda obtener valor de cada incremento.

Para proyectos predictivos:

Fíjate en el cronograma el nivel de impacto que puede tener la variación en la estimación de la actividad, las holguras existen justamente para absorver este tipo de variaciones. Si la variación está dentro de la holgura de la actividad, no hay tanto lío, seguramente el cambio sea aprobado por no tener impacto en cuanto a duración del proyecto.
Si bien una variación pueda ser absorvida por la holgura a nivel de tiempo, queda por validar a nivel de costo si hay un incremento. En este caso puede que tengas que justificar bien el cambio y validar la causa de la variación en la estimación para poder definir a nivel contractual si el proyecto o el vendor debe asumir los costos extra. De cualquier modo, aunque puede ser algo tedioso, las contigencias existen como parte de la linea base de costos para absorver este tipo de sitaciones.
En algunos casos puede que la variación de la estimación de una actividad genere un retraso directo por ser una actividad sobre la ruta crítica del proyecto, en estos casos lo mejor es validar rápidamente si hay un plan de contingencia o riesgo identificado con antelación, así puedes ejecutar dicho plan, sino, mi recomendación es comunicarlo tan pronto como lo hayas identificado y tomar acciones de Crashing o Fast Tracking para compensar con dinero el posible impacto que pueda haber en cronograma. Esto partiendo del hecho que es importante entregar en la fecha acordada.

Conclusiones

Ya que te he contado las generalidades de estimaciones y te he compartido muchos recursos para profundizar cada detalle en particular, empezaré por remarcar el alto nivel de compromiso que se requiere para empezar a utilizar las estimaciones en proyectos ágiles. No es habitual que los niveles gerenciales de una organización estén en su zona confort con estimaciones relativas, donde es posible que puedan variar y no haya nada escrito en piedra. Fueron formados con un mindset lineal, predictivo, que busca ser deterministas cuando se trata de un plan.

Que nuestros gerentes tengan un pensamiento predictivo no es algo que cuestionaré, en el mundo real los recursos como el dinero son límitados y es importante saber si la inversión que sea relizará es posible realizarlo o no. Cuando desviarse del costo inicial es posible por el nivel de capital del sponsor de proyecto, ser imprecisos o trabajar con estimaciones relativas es más fácil de llevar adelante. En cambio, cuando el capital es muy limitado y cualquier desviación puede significar la no conclusión del proyecto y comprometer el éxito del mismo, hacer uso de estimaciones predictivas serán buscadas sin duda alguna.

Mi opinión personal sobre las estimaciones es que tienen un nivel de utilidad muchas veces limitado por querer usarlas como instrumento para medir performance de un equipo, entre los miembros del equipo o incluso entre distintos equipos. Las estimaciones bien llevadas tienden a permitir que un equipo ágil pueda setear expectativas de entrega cada vez más exactas, es decir; que lo que comprometan para entregar en un sprint/iteración sea entregado. Esto construye confianza de parte de los stakeholders hacia el equipo ágil al reconocer que el riesgo de no entrega cada vez es menor. No porque los equipos traten a toda costa de cumplir, disminuyan la calidad o se sobrecarguen, sino porque pueden aproximarse en mejor medida a lo que realmente pueden entregar sin entrar en exceso a partir de su experiencia empírica.

Como dije anteriormente las estimaciones son un “valor cercano” para que un equipo pueda determinar si está dentro de sus posibilidades realizar la entrega y cuanto esfuerzo le tomará, la sumatoria de estas valoraciones les permitirán comparar el compromiso vs su capacidad y tomar la decisión de añadir o remover. No son un mecanismo para comparar entre equpipos, si esta fuera la necesidad, te recomiendo no buscar la respuesta en las estimaciones sino en Valor y en Realización de Valor (Value Realization).

Si eres nuevo en el mundo de las estimaciones mi mejor recomendación es que trates de aprender los detalles antes de lanzar la implementación, esto permitirá tener estructura y seguir un proceso conocido. Con el tiempo verás que cada vez es más fácil estimar y que empieza a existir la sensación que todos están conectados mentalmente, no te preocupes, es normal. Un error que debes evitar es creer que por siempre se seguirá el proceso al pie de la letra, al final lo más importante no es el “número” sino el compromiso que hace un equipo y su nivel de confianza al momento de hacerlo. Con el tiempo tu equipo madurará y no será necesario colocar un número para saber como equipo que es posible su entrega o no.

¡Déjame conocer tus experiencias y opiniones, estaré complacido de leerlas!

Jesus (Yiizux)