ESTIMACIONES ÁGILES

Las estimaciones son ampliamente utilizadas en la mayoría de proyectos tanto tradicionales como ágiles, ya
que los seres humanos, por costumbre, necesitamos catalogar y relacionar las cosas, para facilitarnos la toma
de decisiones, es por ello que al iniciar un proyecto nos preguntemos.
Estimar, nos ayuda, conociendo la magnitud del proyecto y de las tareas que tenemos que asumir, a hacernos
una idea aproximada del tiempo y recursos que vamos a consumir.
Debemos tener claro: las estimaciones son sólo valores aproximados, no son verdades absolutas.
Y si bien es relativamente sencillo hacer estimaciones, debemos tener en cuenta algunos problemas que nos
pueden surgir, como es el Enfoque subjetivo: cada persona en función de su experiencia, su momento
personal y su forma de ser, puede emitir una estimación totalmente diferente a la de otra persona. Además,
la concepción del tiempo, también es algo variable. ¿Dos horas son mucho o poco tiempo?
La estimación no la realiza el Cliente/Product Owner, porque no es él quien se va a “meter en faena” y luchar
por cumplir con unas fechas, ni no que lo hará todo el equipo Scrum (Product Owner, Scrum Máster y
Development Team), de esta forma conseguimos: Reforzar el compromiso de todo el equipo respecto a las
fechas que dan al cliente, reforzar la implicación que cada miembro del equipo siente hacia el otro y hacer
que todos se sientan escuchados.
Planificación de proyecto
El primer paso en la estimación y planificación ágil es la creación del Product backlog, que como sabemos,
para trabajar deberemos dividir en Objetivos (PBIs). Estos los veremos cómo historias de usuario (user
stories), donde cada historia es un requerimiento de nuestro proyecto, visto desde el punto de vista de un
usuario (stakeholder o cliente).
Se escriben con el siguiente formato:

Ejemplo: “Como cliente del supermercado, quiero pedir online para poder tener tiempo de ir al gimnasio”
¿Qué unidades utilizamos para las estimaciones?
La estimación se puede realizar utilizando alguna de las siguientes unidades:
• Los “Días ideales”: o días necesarios para que el equipo pueda completar un objetivo, sin considerar
interrupciones. Para pasar esta unidad a días reales, se suele aplicar un factor de corrección (oscila
entre 60 % al 70 % de dedicación real), y sumar además un extra de tiempo por imprevistos.
• Puntos de “historia de usuario”: la complejidad técnica que tiene cada historia de usuario o PBI, o
el peso estratégico o comercial que tiene la misma y que influye de forma directa en el tiempo que
vamos a precisar en realizar la iteración.
1
La técnica de Planning Poker, permite hacer una estimación inicial del rápida y segura del proyecto, puesto
que todos los miembros del equipo comparten en “cada mano” sus diferentes informaciones y expresan su
opinión sin sentirse condicionados por el resto, siendo un proceso iterativo.
Cada número significa un peso /complejidad / esfuerzos necesarios para completar un objetivo o historia de
usuario. La numeración de las cartas está basada en la sucesión de Fibonacci, en la que la distancia entre
los números crece a medida que estos se hacen mayores.
Como aplicar Planning Poker
• El Product Owner lee un objetivo (historia de usuario escrita en una tarjeta, tipo el post-it que vimos
arriba).
• El equipo le hace preguntas para entender por qué la ha leído y las respuestas quedarán anotadas
como detalles del objetivo.
• Cada miembro del equipo piensa en el esfuerzo necesario para completar el objetivo, y todos
muestran sus cartas (tarjetas) simultáneamente (de esta forma no existe un condicionamiento por las
opiniones de otros).
• Aquellos cuyas estimaciones se alejen más de las de los demás, explican el porqué de su decisión
(si es una estimación más baja, es posible que sepan una manera sencilla de resolver el problema o
bien hayan visto algo parecido en otro proceso anterior. Si es más alta es posible que hayan pensado
en algún problema en el que nadie más ha pensado).
• El equipo vuelve a votar, hasta que alcanza un acuerdo.

Ejemplo de Aplicación de Planning Poker en Estimaciones Ágiles

Para llevar a cabo el caso práctico necesitamos una historia de usuario dentro de un contexto ágil, con lo que
asumamos que se nos ha encomendado … ¡¡un producto espacial!!
“La empresa SpaceXYZ en su programa “Go Mars” plantea llevar a marte provisiones y tripulación en 2024,
a bordo de la lanzadera Starship Trooper I. Dentro de este programa, bajo la dirección de explotación y
marketing se ha lanzado el desarrollo de un producto para gestionar todo lo relacionado con la venta de plazas
de vuelo, admisión de nuevos clientes y gestión de equipajes y carga de la nave. Uno de los aspectos más
controvertidos del programa, es que en cada vuelo a Marte se reservarán un número limitado de plazas para
voluntarios. Estos voluntarios a cambio de trabajar de forma altruista podrán formar parte de la experiencia
de viajar al planeta rojo.”
A continuación, tenemos la Historia a estimar (izquierda) y la Historia que utilizaremos de referencia (derecha).

Historia a estimar (izquierda) – Historia de referencia (derecha)

2
Bien, ya tenemos qué estimar y con qué comparar. P ¿cómo estimamos? ¿cómo jugamos a Planning
Poker?
¿Cómo aplicamos Planning Poker?
En el proceso de Planning Poker se reparte una baraja con valores en puntos de historia que siguen una
progresión típicamente relacionada con la serie de Fibonacci. Los valores más habituales de estas barajas
suelen ser 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100, “?” e infinito.

Baraja típica de Planning Poker

Una vez que todos los integrantes del equipo tienen una baraja, se lee en alto la historia, se discute sobre
la complejidad y riesgos y se aclaran las posibles dudas que surjan con el Product Owner. Se recuerda, en
el caso que sea necesario, la historia acordada como marco de referencia con la que se van a comparar las
historias a estimar.
Tras una primera discusión entre el equipo, cuando haya quedado más o menos claro el qué es lo que hay
que hacer, cada miembro elige una carta de la baraja, y una vez que todos hayan elegido su carta se ponen
boca arriba. Se ha realizado la primera votación.

Resultado de la primera votación.

Bueno, analicemos que información nos arroja esta primera votación:
En primer lugar, tenemos dos miembros del equipo que estiman la Historia de Usuario en 3, hay otros tres
miembros del equipo que consideran que pesa 5 y John Doe considera que son 13 los puntos de historia que
debía pesar esta historia.
Rápidamente podemos atisbar que no tenemos consenso y, en particular John estima la tarea 4 veces más
compleja que dos de sus compañeros. Ante este escenario, hay que interpretar que John ha podido ver algo
que el resto de sus compañeros no han visto. Para averiguarlo hay que invitarle a que explique los
motivos por los qué ve mucho más compleja la Historia de usuario que el resto de sus compañeros.
Estos son los argumentos que han llevado a John a estimar 13:

3
John: “Chicos creo que no estáis teniendo en cuenta que la misión es internacional y podrían inscribirse
voluntarios de varios países. Esto implica que hay que tener en cuenta cargar los códigos postales de todos
los países de los que se admiten candidatos y soportar además inscripciones en idiomas con caracteres
chinos, japoneses, coreanos o cirílicos”
Tras la exposición de John, el equipo vuelve a discutir sobre las implicaciones que comenta John. Llegados
a este punto varios miembros del equipo podrían incrementar su votación gracias a los motivos que ha
expuesto John, incluso John podría reducir el peso de su votación si alguno de los contra-argumentos de sus
compañeros le convencieran. Tras llegar a un entendimiento de la nueva complejidad y riesgo de la Historia
se vuelve a votar.

Resultado de la segunda votación.

En esta segunda votación una buena parte del equipo ha sido consciente de que el desarrollo parece mas
complejo de lo que en un inicio planteaba. Sin embargo, John sigue viéndola muy compleja y Jane la sigue
viendo simple. Es más, Jane ve la Historia con una complejidad menor de la mitad de lo que estima John.
¿Qué debemos hacer? De nuevo hay que hacer aflorar las razones que generan esta discrepancia y para eso
nada mejor que el hecho de que ambos expliquen que ha motivado dicha estimación.

John: “Ya os he comentado que no es tan fácil como pensáis”

Jane: “Bueno, si bien es necesario que se soporten varios tipos distintos de caracteres, esto no debería afectar
demasiado ya que el framework sobre el que se va a apoyar el desarrollo, lo resuelve:”
Estos argumentos deben generar una nueva discusión en el equipo y una nueva votación hasta que se llegue
a un acuerdo sobre cuál será la estimación asociada en la historia. En nuestro ejemplo, en la tercera votación
tenemos:

¡Et voila! Ya tenemos consenso y valor de estimación para la historia: 8

Este es un devenir habitual en las estimaciones llevadas a cabo en Planning Poker. Los equipos menos
maduros, o que lleven poco tiempo trabajando juntos, discreparan en un inicio más que los maduros.

4
En la realidad no suelen hacer falta más de tres iteraciones – votaciones, para converger en un valor
de estimación. Suele ocurrir también, que aquellos que en una votación estiman muy alto una historia, en la
siguiente votación suelen encontrarse en el caso contrario dando una estimación más baja del consenso.
Y recuerda, lo más importante es que, mediante estas discrepancias y discusiones, el equipo logra un
mejor entendimiento y detalle de la tarea a abordar y genera complicidad y compromiso.
En resumen …
Una vez visto el ejemplo, vamos a resumir el proceso que se ha seguido en él para llevar a cabo la estimación.
PRE-REQUISITOS:
Antes de comenzar, necesitamos una (o varias si aplicamos triangulación) historia de referencia con la que
comparar las historias a estimar y algo que estimar.
PASOS:
1. Para empezar, se lee la Historia de Usuario en alto y se discuten sus
distintas interpretaciones hasta llegar a un acuerdo mínimo de entendimiento.
2. Si es necesario, se lee la Historia de Usuario o tarea que se ha acordado de referencia.
3. Una vez entendidas ambas se vota el “tamaño” de la Historia de Usuario.
4. Si no hay consenso, se da la palabra a los miembros del equipo con estimaciones muy bajas o muy
altas, quizás ellos hayan visto algo que al resto les haya pasado desapercibido.
5. Se discute nuevamente con estos nuevos argumentos y se vota de nuevo.
6. Y se sigue votando y discutiendo hasta consensuar un valor de estimación.

Preguntas frecuentes:
Si un equipo no termina poniéndose de acuerdo con la estimación, ¿Cómo acordamos un valor de
estimación?
Si tras varias iteraciones este resultado se mantiene, y no existe forma de ponernos de acuerdo, se suele
tomar la decisión de adoptar la estimación mayoritaria. Pero el valor en sí que acordemos es indiferente. Si
han aflorado una buena cantidad de dudas y preguntas que han logrado un mejor entendimiento de la Historia,
hemos llegado al objetivo de nuestra estimación. Y si nos equivocamos lo veremos al final del Sprint y
aprenderemos de ello.
¿Qué pasa si alguien saca la carta de 0?
La carta de 0 implica que la tarea tiene un valor despreciable, es común que pueda salir y no tiene más
importancia.

¿Qué pasa si alguien saca la carta de ∞?

¿Y ahora qué? La carta de infinito implica que la historia en sí no se puede abordar por el momento porque
no se dispone de la información necesaria para poder estimarse. Es posible que esté recién recogida y por
tanto tenga poco detalle, el Product Owner tiene que darle aún más forma antes de ser “estimable”. Que sea
estimable es uno de los aspectos más importantes a la hora de escribir una historia. Recuerda que las historias
bien escritas deberían seguir el Acrónimo INVEST: independent, negotiable, valuable, estimable, short y
testable.
¿Qué pasa si alguien saca la carta de Café?
Quien saca la carta de café es porque ya no puede con su vida (estimadora) y necesita gasolina, si tiene
sentido en este momento, ¿por qué no hacemos un alto en el camino?