Estimación en proyectos ágiles

Estimación de historias

Actualmente existen varias tendencias a la hora de estimar historias, entre ellas la de no estimar o la de estimar en tiempo o en complejidad, como Javier Garzás nos muestra en varios de sus posts:

• https://www.javiergarzas.com/2019/07/agilidad-viejuna.html
• https://www.javiergarzas.com/2019/04/no-estimar-noestimates-en-el-mundo-real.html
• https://www.javiergarzas.com/2018/03/puntos-historia-horas-o-complejidad.html

En mi caso os voy a contar mi experiencia, empezando con un equipo acostumbrado a un modelo waterfall o a un modelo basado en ejecución de tareas simple.

Paso 1. Introducir al equipo en metodologías ágiles

Es muy imporante que el equipo antes de empezar en este mundo sepa de qué estamos hablando, entienda la filosofía detrás de los principios y valores que hay detrás de Agile. Luego con el tiempo, irá definiendo sus propios valores y principios, pero sin dejar a un lado los ya adquiridos como base de Agile.

Se trata de una paso importante y complicado, tienes que ser capas de liderar este cambio con tu equipo, sino, directamente no pases al siguiente paso.

Paso 2. Empezamos con la definición del producto

Detrás de todo proyecto debe haber una idea para obtener un producto. En el concepto del producto intervienen varias figuras:

• Product Owner, como figura que conoce la necesidad inicial, tiene un visión muy claro y tiene el poder de decidir lo que se hace y lo que no durante el transcurso del proyecto.
• Organización, como figura que conoce los procesos actuales de la empresa y ayuda a entender donde enmarcar este producto dentro del proceso, incluso a participar en el rediseño del proceso si el producto así lo requiere.
• Legal, para contemplar todos los aspectos legales o de RGPD que conlleve la ejecución del proyecto.
• Representante/s de los usuarios, para ver como se refleja el producto en el día a día de un usuario
• Diseñador / UX, para ayudar a visualizar el producto
• Scrum Master, para tener esa visión que ayude luego al equipo en todas aquellas dudas o bloqueos.

La forma de llegar a un punto común que satisfaga a todos es ir iterando sobre ideas y propuestas, hasta llegar al modelo para la siguiente fase de lo que se le pedirá al producto (no hemos dicho que sea el modelo final).

Paso 3. Definimos el mapa de historias de usuario

En este paso, se trata de sacar el guión después de ver una película cuando lo normal es al revés :). Para ello se prepara una reunión o varias, según lo complejo que sea el producto, en la que se transmite al equipo el modelo del producto al cual se ha llegado en el paso anterior.

En esta reunión intervienen:

• Product Owner
• Representante/s de los usuarios
• Diseñador / UX
• Scrum Master
• Equipo desarrollo
• I+D+i 

El Product Owner transmite la "película" tal cual la han concebido en el paso anterior y el equipo empieza con las preguntas en cualquier momento para ir entendiendo lo que se necesita.

Una vez terminada la exposición, se empieza a definir el mapa de historias de usuario por parte del equipo de desarrollo. Este punto tendría que tenerlo realizado el Product Owner, definiendo la Pila, pero lo hacemos así para hacer partícipe al equipo y que todos entiendan lo mismo cuando se está escribiendo la historia, evitando mal entendidos (recordar que la comunicación es un punto muy importante dentro de las metodologías ágiles).

La figura de I+D+i ayudará a ver que parte de innovación se puede incluir en el proyecto para mejorar la solución propuesta. El equipo de desarrollo se trata de un equipo multidisciplinar de alto rendimiento, pero en ellos no recae la responsabilidad de I+D+i, sino la de hacer productos que funcionen.

Se trata de un mapa de historias a muy alto nivel, sin estimar.

Paso 4. Refinamiento de la pila

Entramos ahora en otras series de iteraciones en las que el equipo va trabajando ese mapa de historias, planteando dudas al Product Owner y/o al Scrum Master, para llegar a un mapa de historias nuevo en el que se sientan cómodos para estimar. Este mapa debe de estar consensuado por el Product Owner y debe de participar en su redefinición (recordar que él es el propietario de la pila).

Este refinamiento no debería de ir más allá de una semana de duración, estamos en lo que denominamos Sprint 0.

Al final, tendremos el modelo final, en el que el equipo ha tenido la "ayuda" de tener una base sobre la que trabajar.

Como punto adicional en este paso, si tu equipo dispone de la figura de QA, es importante que vaya entrando en escena, para participar desde el inicio y no al final, revisando los criterios de aceptación que vaya definiendo el Product Owner y definiendo los criterios de done. Pero esto es tema de otro post :)

Paso 5. Estimación

Ahora es el turno de estimar. Partimos de que es nuestro primer proyecto y no tenemos nada con lo que empezar, con lo que estimamos de forma relativa y con complejidad: ¿esta historia es más o menos compleja que la anterior? o ¿tiene la misma complejidad?

Esto nos dará un mapa en dos dimensiones, de izquierda a derecha de menos a más complejo, y de abajo a arriba de más a menos prioritario dentro de una misma complejidad.

A partir de aquí, recordar que es nuestro primer proyecto, empezamos a dar puntos de historia a las historias siguiendo la serie de Fibonacci. Empezamos con 1 si consideramos que la primera columna tiene una complejidad trivial. Luego seguimos con la siguiente columna y vemos si la complejidad es el 2,3,5,... y así sucesivamente, hasta tener todas las historias puntuadas.

Una vez terminado el ejercicio de puntuación, vemos aquellas historias con 5 o más puntos.  La idea es tener historias lo más pequeñas posibles, y como indica Javier Garzás, cuanto más se parezcan entre ellas mejor.

Cogemos esas historias y vemos si es posible separarlas con el Product Owner en historias más pequeñas. Sabemos que estamos estimando y como toda estimación nos vamos a equivocar, el margen de error será mayor cuanto más compleja sea la historia (más puntos), por eso buscamos historias lo más pequeñas posibles.

Paso 6. Priorización y posible calendario

Una vez tengamos el mapa estimado y cerrado, nos queda que el Product Owner lo priorice y en base a la velocidad que el equipo estime (cuántos puntos de historia va a poder abordar en un sprint) se irán definiendo los objetivos de cada sprint junto al gráfico de burn-up.

Paso 7. Ejecución del proyecto

Ya nos metemos de pleno en Scrum, no siendo caso de estudio en este post.

Durante la ejecución del proyecto, y en los primeros 2 o 3 proyectos, la velocidad se irá ajustando, hasta llegar a una velocidad adecuada y que el equipo se sienta cómodo con las estimaciones.

Paso 8. Retrospectiva

En este paso, el equipo revisará si las complejidades que había transformado en puntos de historia se adecuaron a la realidad en el transcurso del proyecto, en caso contrario, harán los ajustes oportunos para en las siguientes estimaciones tener un menor porcentaje de equivocación.

De igual modo, analizarán la velocidad media a la que han ido, sin perder de vista el peor y mejor sprint, para ayudar luego a preparar un mejor burn-up en el siguiente proyecto.

Conclusiones

Con el tiempo, el equipo irá adquiriendo esa experiencia y esos conocimientos para que las estimaciones se conviertan en una no estimación, pues sabrán ya definir historias junto al Product Owner más o menos pequeñas y de una complejidad similar para tener una velocidad media más o menos continua.

Dentro de este modelo, centra expectativas al cliente final, y no des una fecha de fin de proyecto, sino un periodo en el que se podría entregar el proyecto, tanto por errores en las estimaciones iniciales como cambios surgidos durante la iteración del proyecto para adaptarse y mejorar la experiencia de usuario. Esto siempre ayudado sprint tras sprint de la actualización del burn-up y haciendo gestión por excepción cuando preveas que la desviación sobre el ideal está por encima de un x % pactado con el cliente final.