Estimación

ADRIANA XIOMARA REYES GAMBOA PHD.

En Scrum se utilizan los puntos historia en lugar de horas-hombre o cualquier otra unidad basadas en tiempo
 Scrum y  lo puntos de historia

Vemos cómo funcionan los puntos de historia  en dos sencillos pasos:

1.Definición de la referencia
Escogemos una historia de usuario sencilla, una que todo el mundo entiende,
para emplearla como referencia. Esta sería la definición de 1 punto de la historia
en nuestro proyecto.

2.Estimación
Establecida la referencia, cada vez que queremos estimar algo tan solo tenemos
que  compararlo con la historia de referencia. Si creemos que nos llevará el
doble de trabajo que la historia de referencia, entonces el valor será de 2 puntos
de historia; si creemos que tarda la mitad del esfuerzo, sería 0.5 puntos; etcétera.
 Los puntos de historia son convertibles en tiempo.
Lo hacemos empleando el concepto de «velocidad»

• Digamos que el resultado, o los puntos de historia que hemos podido concluir transcurridos
5 sprints ha sido el siguiente:
• Nº1: 73 puntos
• Nº2: 110 puntos
• Nº3: 98 puntos
• Nº4: 131 puntos
• Nº5: 122 puntos
• En este caso, podemos decir que, en promedio, hemos entregado 107sp por Sprint. Esto es lo
que llamamos «la velocidad». Nuestra velocidad al final del quinto Sprint es 107puntos de
historia por Sprint.
 Los puntos de historia son convertibles en tiempo.
Lo hacemos empleando el concepto de «velocidad»

Por lo tanto, en base a este datos podemos calcular la siguiente

información:

La cantidad de trabajo que podríamos realizar en el siguiente Sprint:

alrededor 107 puntos.

Si actualmente tenemos un Backlog de Producto con un valor estimado de

1000 puntos, y no pensamos añadir nuevas historias de usuario.
¿Cuándo estimamos que podríamos terminar el proyecto? 
1000 puntos / 107 puntos por Sprint = unos 10 sprints
Por supuesto, la velocidad es algo que cambia constantemente.

Por ejemplo, si nuestra producción es de 140 putos durante el 6º Sprint, la

velocidad se modificaría a 112 puntos.
Así pues, cada Sprint concluido es una oportunidad para ajustar todos los
cálculos y realizar previsiones más realistas.
Al inicio del proyecto es normal que se produzcan grandes cambios de
velocidad. Digamos que esta se estabiliza entre el quinto sprint.

Cycle Time
La unidad de medida entonces en scrum son los (puntos de historia)
y quiénes son los responsables de realizar las estimaciones.

Imaginemos un equipo de 6 desarrolladores: el Dueño del Producto

les ha presentado un nuevo elemento del Backlog de Producto, ya
han discutido y aclarado el contenido, así que solo queda realizar la
estimación. ¿Cómo lo hacen? ¿Deben votar uno por uno?
La estimación ágil
En la estimación ágil perseguiremos los siguientes objetivos:

• Tener diferentes puntos de vista. En la estimación ágil se busca la democracia, que todo el

mundo participe y diga la suya. No debería haber personas con una voz y voto más fuertes
que los demás.
• Detectar posibles tareas ocultas y posibles obstáculos. La sesión de estimación es una de
las primeras oportunidades de detectar riesgos que pueden comenzar a tratarse para que
no se conviertan en impedimentos.
• Tener una visión compartida de la que se viene encima. Es muy útil haber participado en
las estimaciones para después hacer las planificaciones. Si conoces el tamaño de las
historias y tareas es mucho más sencillo comprometerte con un plan de trabajo que si las
estimaciones te vienen “impuestas”.
• Tener estimaciones más realistas (no más precisas). La idea es que entre todos el numerito
que salga sea lo más cercano a la realidad posible.
Planning Poker

• Una de las técnicas más efectivas y conocidas del mundo ágil para
estimar es el Planning Poker. Se trata de una dinámica ágil en la que se
reúne el equipo con una baraja de Poker modificada y se hacen rondas
de estimación con ayuda de estas cartas.
• En cada baraja hay una pseudo-secuencia de Fibonacci modificada.
Cada participante tendrá las siguientes cartas: 0,1/2, 1, 2, 3, 5, ? e
infinito. El cero significa que la historia ya está hecha o no requiere
ningún esfuerzo, el interrogante significa que nos falta información para
estimar esa historia o tarea y el infinito es que es demasiado grande y
hay que dividirla.
Dinámica de la sesión

• Todo el equipo “se encierra” para estimar, y todos conocen lo que se va a estimar. Si
hay gente que no está al tanto de lo que se va a estimar la sesión debe comenzar con
una explicación y una sesión de preguntas para despejar cualquier duda sobre las
historias que se van a estimar.
• Una por una se leen y discuten las historias de usuario. Una vez todos tienen claro en
qué consiste cada uno elige una carta en función del esfuerzo que prevé requerirá esa
historia. No es posible seleccionar un valor no incluido en la baraja. Solo estiman los
que después desarrollan (ni el Scrum Master ni el Product Owner estiman, solo
resuelven dudas).
• Si no hay consenso (lo normal con más de 2 participantes) se abre la discusión. No muy
larga, por ejemplo se puede hacer que explique su elección el que tiene la puntuación
más baja y más alta. Se repite la estimación nuevamente en busca de consenso. Si no
se consigue a la segunda se vuelve a discutir. A la tercera si no hay consenso se escoge
o bien la media o bien el máximo (mejor el máximo).
• Al final de la sesión el resultado es una estimación consensuada y validada por todo el
equipo para cada una de las historias o tareas seleccionadas.
¿Que por qué funciona Planning Poker?

Porque unifica la opinión de varios

expertos en lugar de depender de uno,
ayuda a identificar más riesgos más
pronto, define una visión única del
trabajo por hacer, y obliga a defender las
estimaciones dadas ante los
compañeros.
MUCHAS GRACIAS