Estimando el Backlog Hablemos de tcnicas simples como el planning poker o la estimacin por anidad.

El planning poker funciona en parte dado que tiene una slida base terica, pero sobre todo porque quienes estiman son aquellos que en denitiva llevarn a cabo el trabajo. El planning poker es rpido. Un equipo con prctica estimar en promedio un tem cada 3 minutos. El planning poker es preciso. Las estimaciones obtenidas utilizando planning poker son tan buenas como las obtenidas usando mtodos tradicionales.

Estimando el Backlog

La estimacin por anidad es an ms rpida que el planning poker. Es genial para equipos que tienen un backlog completo para estimar y el tiempo es ms importante que una gran precisin y distribucin del conocimiento.

Algunas aclaraciones: Estimamos los tems de forma relativa entre ellos. Por qu? Resulta fcil acordar que esta historia tiene el doble de complejidad que esta aunque no sepamos an cunto tiempo tomar implementarlas. Estimamos los tems usando unidades de complejidad en vez de unidades de tiempo. Por qu? Esto nos escuda frente a la necesidad de ajustar las estimaciones dependiendo de quin realiza el trabajo o cuando las habilidad y capacidad del equipo cambian con el correr del tiempo.

Algunas aclaraciones:

Usamos una escala no linear porque la diferencia entre 1 y 2 es obviamente ms significativa que la que hay entre 20 y 21. En general se usa la escala basada en la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40 and 100. Luego se define el rango que va del 1 al 8 (o incluso al 13) como los posibles tamaos de los tems que un equipo puede desarrollar durante un sprint. Los nmeros ms grandes se dejan para historias ms grandes (picas), que debern ser subdivididas en pequeas historias antes de ingresar a un sprint.

Estimacin inicial la valoracin inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias.

La unidad son puntos de historia y usualmente corresponde a das-persona ideales.

Pregunta al Equipo: si te enfocas 100% con tu equipo (por ejemplo: son 3 en el equipo de desarrollo) y trabajas sin distracciones, en cuantos das saldrais con una implementacin terminada, demostrable, testeada y liberable?. Si la respuesta es entre los 3 tos encerrados y trabajando a full nos llevara 4 das, entonces la estimacin inicial son 12 puntos. 3 personas x 4 dias= 12 puntos. Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 das), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debera durar la mitad que una historia de 4 puntos).

Estimando usando clculos de velocidad

Esta tcnica consta de dos pasos 1. Decidir la velocidad estimada 2. Calcular cuntas historias se pueden aadir sin sobrepasar la velocidad estimada La velocidad es una medida de cantidad de trabajo realizado, donde cada elemento se evala en funcin de su estimacin inicial.

As que, mediante qu tipo de magia arcana estimamos la velocidad? Una manera muy fcil de estimar la velocidad es revisar la historia del equipo. Cul fue su velocidad durante los ltimos Sprints? Y entonces asumir que la velocidad ser ms o menos la misma en el prximo Sprint. Esta tcnica se conoce como el tiempo que hizo ayer. Solo es factible para equipos que ya han hecho algunos Sprints (de forma que haya estadsticas disponibles) y que harn el prximo Sprint ms o menos de la misma manera, con el mismo tamao de equipo, las mismas condiciones de trabajo, etc.

Una forma ms sofisticada de hacerlo es realizar un simple clculo de recursos. Digamos que estamos planificando un Sprint de 3 semanas (15 das laborables) con un equipo de 4 personas. Lisa estar de vacaciones 2 das. Dave slo estar disponible al 50% y estar un da de vacaciones. Ponindolo todo junto

Es esta nuestra velocidad estimada? No! Porque nuestra unidad de estimacin son puntos de historia lo que, en nuestro caso, corresponde ms o menos a das-hombre ideales. Un da-hombre ideal es un da perfectamente efectivo, sin distracciones, lo cul es raro. As que nuestra velocidad estimada ser sin duda menor de 50. Pero cuanto menor? Para esto usamos el factor de dedicacin.

El factor de dedicacin es una estimacin de cmo de centrado va a estar el equipo. Un factor de dedicacin bajo puede significar que el equipo espera encontrar muchas distracciones e impedimentos o que considera que sus propias estimaciones son optimistas. La mejor manera de determinar un factor de dedicacin razonable es estudiar el ltimo Sprint (o incluso mejor, la media de los ltimos Sprints).

La velocidad real es la suma de las estimaciones iniciales que se completaron en el ltimo Sprint. Digamos que en el ltimo Sprint se completaron 18 puntos de historia utilizando un equipo de 3 personas formado por Tom, Lisa y Sam trabajando las tres semanas hasta un total de 45 das-hombre. Y ahora estamos intentando calcular la velocidad del prximo Sprint. Para complicar las cosas, un nuevo tipo, Dave, se une al equipo para este Sprint. Teniendo en cuenta las vacaciones y dems asuntos tenemos 50 das-hombre ideales este Sprint.

As que nuestra velocidad estimada para el prximo Sprint es de 20 puntos de historia. Eso significa que el equipo debe aadir historias al Sprint hasta que sume aproximadamente 20. El factor de dedicacin por defecto que usamos para equipos nuevos es habitualmente el 70%, dado que es ah donde terminan la mayora de nuestros otros equipos con el tiempo.

Estimacin de tiempos usando planning poker

Cada miembro del equipo cuenta con una baraja de 13 cartas, como las que se muestran en la imagen. Cada vez que hay que estimar una historia, cada miembro del equipo selecciona una carta que representa su estimacin de tiempo (en puntos de historia) y la coloca bocabajo en la mesa. Cuando todos los miembros del equipo han preparado sus cartas, se les da la vuelta al mismo tiempo. As obligamos a cada miembro del equipo a pensar por si mismo en lugar de seguir la estimacin de otro. Si hay mucha discrepancia entre dos estimaciones, el equipo discute las diferencias y trata de construir una imagen comn del trabajo necesario para la historia. Pueden hacer algn tipo de divisin en tareas. Despus, el equipo estima de nuevo. Este bucle se repite hasta que la estimacin de tiempo converge, es decir, que todas las estimaciones sean aproximadamente las mismas para esa historia.

Dividiendo historias en historias ms pequeas

Creo que casi siempre es posible dividir una historia grande en historias ms pequeas. Simplemente asegrate de que las historias pequeas siguen representando entregables con valor de negocio. Normalmente buscamos historias con estimaciones de 2 a 8 das/hombre. Nuestra velocidad es usualmente 40-60 para un equipo tpico, as que eso nos da para unas 10 historias por Sprint. A veces slo 5, y a veces hasta 15. Es un nmero de tarjetas gestionable con el que trabajar.

Cmo puede el Dueo de Producto alterar las historias que se incluyen en el Sprint?

Al Dueo de Producto no le gusta que la historia D no se vaya a incluir en el Sprint. Cules son sus opciones durante la reunin de planificacin de Sprint? Una es re-priorizar. Si le da al elemento D la mayor importancia, el equipo se ver obligado a aadirlo al Sprint en primer lugar (descartando en ese caso la historia C).

La segunda opcin es cambiar el alcance reducir el alcance de la historia A hasta que el equipo crea que la historia D podra caber en el Sprint.

La tercera sera dividir una historia. El Dueo de Producto podra decidir que hay algunos aspectos de la historia A que no son tan importantes, as que dividira la historia A en dos historia A1 y A2 con diferentes niveles de importancia.