Las estimaciones son ampliamente utilizadas en la mayoría de proyectos tanto
tradicionales como ágiles. Es bastante humano necesitar catalogar y relacionar las
cosas. Eso nos permite poder tomar decisiones de forma muy sencilla. Por ello, al
iniciarse un proyecto suele ser habitual preguntarse cuánto pensamos que nos va
llevar. De ahí que se realicen estimaciones iniciales siguiendo diferentes técnicas
para tratar de dar respuesta a esta pregunta.
No es malo estimar, al contrario, nos ayuda a hacernos una idea de la magnitud de
las cosas y poder tomar decisiones. Lo que sí que debemos tener claro es que las
estimaciones son sólo eso, estimaciones, es decir, valores aproximados que nos
servirán para tomar decisiones. No son verdades absolutas o compromisos grabados
en piedra que suele ser la cara B de las estimaciones.
Al pedir una estimación estamos en el fondo pidiendo un compromiso de la otra
persona. Al dar una estimación nos estamos comprometiendo indirectamente.
Es ahí
donde se tergiversan las cosas y donde pierde el verdadero sentido las
estimaciones, como herramienta de ayuda a la toma de decisiones y pasan a ser
instrumento para exigir y culpabilizar.
Por eso, utilicémoslas con cabeza y cuidado como herramienta que fomente el
dialogo entre todos los intervinientes en un proyecto y no como un instrumento de
ataque o defensa. Recordemos que las metodologías ágiles se enmarcan dentro de
un contexto de colaboración sobre la negociación por lo que para conseguir que los
proyectos sean exitosos resulta de vital importancia no perder esto de vista.
PUNTOS HISTORIA
Existen diferentes técnicas y herramientas para estimar. También existen diferentes
unidades en las que hacerlo. Veamos algunas de estas a continuación
- Días ideales: Resulta bastante habitual el uso de los días u horas ideales para estimar los proyectos y las tareas. Es relativamente sencillo hacer este tipo de estimaciones y además el ser humano está acostumbrado a pensar en tiempo por lo que resulta bastante natural hacerlo. El principal problema de este enfoque es que es un enfoque subjetivo. Para cada persona en función de su experiencia, su contexto, su forma de ser (optimista, pesimista) puede emitir una estimación totalmente diferente al de otra persona. Además, que la concepción del tiempo en sí misma es algo subjetivo. ¿Cuánto son 4 horas? ¿mucho / poco? Además, hay que introducir otra variable en este tipo de estimaciones. Siempre pensamos en tiempo ideal, es decir, tiempo que nos llevaría sin interrupciones ni problemas. Ya sabemos que la realidad es muy diferente y 2 horas de trabajo real pueden haber sido 30 minutos de trabajo efectivo (o a veces menos). Sin embargo, utilizar esta medida de estimación nos lleva al error de pensar que la estimación en horas / días ideales es realmente una estimación de la “realidad”, es decir, que tendemos a pensar que si hemos realizado una estimación de 2 horas para una tarea vamos a tardar realmente 2 horas desde que nos ponemos hasta que la acabamos. Todos sabemos que esto nunca sucede y el tiempo real será muy diferente del estimado.
- Estimación relativa, puntos historia: Para evitar los problemas de las estimaciones en días ideales los enfoques ágiles promueven otro tipo de estimación relativa basada en puntos historia. El punto historia no es más que una medida “inventada” cuyo único objetivo es el de realizar estimaciones basándonos en complejidades y no en tiempos. De esta manera, tendremos que elegir primero una tarea base sobre la que comparar el resto de tareas. A esta tarea base si es muy sencilla le podemos asignar el valor de 1. En otras ocasiones podemos seleccionar una tarea de complejidad media y asignarle por ejemplo un 3. De esta manera podremos ir comparando. A continuación, una vez elegida esa tarea base y asignándole unos puntos historia concretos pasamos a seleccionar la siguiente tarea a estimar. Esta tarea la analizaremos desde el punto de vista de la complejidad con respecto a la tarea base. De tal manera que si la tarea base le asignamos un punto historia y la tarea con la que estamos ahora vemos que es bastante más compleja, lo suficiente al menos para que sea el doble, pues le asignaremos dos puntos de historia. Así iremos trabajando sucesivamente el resto de tareas. El método que utilicemos es indiferente. La mayoría de equipos ágiles cuando están comenzando utilizan el Planning Poker como técnica de estimación, pero hay muchos equipos que según van avanzando evitan esta técnica y simplemente dialogan sobre ello en la reunión de planificación y durante el refinamiento.
TIPOS DE ESTIMACIONES
Para la estimación existen diferentes aproximaciones en función de los equipos. Hay
que tener presente que el principal objetivo desde el punto de vista ágil es el de
generar conversación entre los miembros del equipo de tal manera que aparezcan
los problemas, bloqueos y soluciones de los PBIs del sprint en curso.
Hay equipos que prefieren desgranar los PBIs en tareas técnicas y estimar cada una
de estas tareas técnicas para posteriormente sumar cada una de estas estimaciones
y dar una estimación global de PBI.
Otros equipos, en cambio, prefieren estimar directamente el PBI, aunque hayan
desgranado también en tareas más pequeñas.
Planning Poker: Es una técnica para hacer estimaciones en equipo, y llegar al
consenso sin perder demasiado tiempo.
El procedimiento es el siguiente:
En la reunión de planificación se le entrega a cada estimador un conjunto completo
de tarjetas.
La reunión prosigue de la siguiente manera:
- El Scrum Master, que no jugará, facilitará la reunión.
- Se van presentando los distintos elementos a estimar donde se proporciona una breve introducción sobre el elemento. El equipo tiene la oportunidad de hacer preguntas y discutir para aclarar los supuestos y riesgos.
- Cada persona coloca una tarjeta boca abajo que representa su estimación. Las unidades utilizadas pueden ser variadas y definidas previamente. Pueden ser días de duración, días ideales o puntos de la historia. Durante el debate, los números no debe ser mencionados en absoluto.
- Todo el mundo muestra sus tarjetas de forma simultánea. A las personas con estimaciones altas y bajas se les da un tiempo para ofrecer su justificación para la estimación y la discusión continúa.
- Se repita el proceso de cálculo hasta que se alcance un consenso.
- Se puede utilizar un reloj de arena para asegurar que el debate sea estructurado, el moderador podrá en cualquier punto terminar el reloj y cuando se acaba toda discusión debe cesar y otra ronda de póker se juega.
Las cartas están numeradas de esta forma para explicar el hecho de que, cuanto una
estimación es mayor, existe mayor incertidumbre. Así, si un desarrollador quiere jugar
un 6 se ve obligado a reconsiderar y aceptar que parte de la incertidumbre percibida
no existe y jugar un 5, o aceptar una estimación más conservadora de la
incertidumbre y jugar un 8.