S, M o L?

En distinas etapas de nuestros proyectos nos encontramos con la necesidad de estimar. Estimar una fecha de entrega, estimar el esfuerzo que demandará completar ciertas tareas...

En un proyecto ágil, tenemos que tener claro que vamos a requerir estimaciones de diferentes niveles: Release, iteración, tareas del día (Podemos identificar otros niveles, pero por ahora nos alcanza con estos, ya vamos a agregar otros cuando los necesitemos, Inspect and Adapt!). Hoy nos vamos a centrar en las estimaciones a nivel de Release e iteración.

Las primeras estimaciones que realizamos de nuestro Product Backlog, las hicimos según Ideal Days. En ese momento, pensamos que iba a ser natural para el equipo pensar en "cuánto lleva realizar estas tareas si me encierro en una pieza con suficiente comida y sin interrupciones hasta terminarla". Permitía estimar de forma parecida a cómo se hacía hasta ahora, dividiendo una funcionalidad en tareas, asignando las tareas a cada miembro del equipo, y luego estimando según cuánto llevaría cada tarea según quién la fuera a hacer. Pero encontramos varios problemas:

• Impide sacar el foco de las tareas y ponerlo en la funcionalidad (valor para el negocio)
• La estimación se hace pensando en cuál es la persona que se cree que va a hacer la tarea ("mis" días ideales no son iguales a "tus" días ideales). Esto va en contra de lograr la responsabilidad como equipo, que cualquier miembro del equipo va a realizar la tarea en el momento en que sea necesario hacerla (aunque lo más probable es que los Stored Procedures los haga nuestro gurú de base de datos).
• Observamos que desde fuera del equipo no dejaron nunca de preguntar "Cómo puede ser que un programador sólo complete 12 días ideales en un Sprint de 20 días? El resto del tiempo que estuvo haciendo?". No importa que en la demo se queden maravillados con la cantidad y calidad de funcionalidad que se completa en un Sprint, en todos los Sprints (al menos esa es la idea :)
• A través del tiempo, la unidad Ideal Days no debería ser comparable, porque el equipo es cada vez más productivo, conoce mejor la tecnología, se conoce a sí mismo, conoce el dominio, entonces las estimaciones en Ideal Days son cada vez menores.

Frente a esta situación, y luego de investigar sobre el tema (recomendado: Agile Estimating and Planning de Mike Cohn), decidimos empezar a estimar mediante Story Points.

Qué es eso de los Story Points?

• Es una medida del tamaño relativo de un item del backlog

Nada más y nada menos. Lo más importante es que mide en forma relativa el tamaño de un item del backlog. La unidad de medida no es muy importante: Podrían ser talles de remera (S, M, L, XL...), podrían ser perros (Chihuaha, Pequinés, Collie, Gran Danés), o simplemente números.

Nosotros elegimos el siguiente conjunto de números: 1, 2, 3, 5, 8, 13, 20, 40. Se parece a una serie de fibonacci, "redondeada" a medida que va creciendo para quitar importancia a la precisión (no nos importa si a un item le vamos a asignar 20, 21 o 24, nos importa saber que aproximadamente es un50% más grande que uno de 13).

Tal vez no sean los "números ideales", se suele sugerir que exista sólo un orden de magnitud entre el item más chico y el más grande (eso dejaría afuera al 13, al 20 y al 40). Nosotros vamos a ser ágiles en esto, primero vamos a probar y después ver el resultado. Inspect And Adapt.
Ya hemos realizado la primer estimación con Story Points, y observamos lo siguiente:

• El equipo tuvo que jugar inicialmente a asignar Story Points a Stories que ya fueron completadas. Con eso planteamos una base para poder comparar futuros Stories y asignarles Story Points.
• El equipo puede estimar los Stories en mucho menos tiempo que antes. Se llega a acuerdos rápidamente.
• Cuando se está estimando, no se piensa en quién va a realizar cada tarea. Lo importante es poder estimar el tamaño relativo. Ya vamos a poder saber cuánto tiempo nos va a llevar cuando sepamos nuestra velocidad. Esto es un gran avance!
• Todavía no nos enfrentamos a la difícil tarea de explicar a la "gente de afuera" esta nueva forma de estimar. Pero confiamos en que vamos a lograr que compren el concepto.

Esto es todo por hoy, más adelante vamos a contar cómo son nuestras sesiones de estimación, las distintas variantes que fuimos adoptando y los resultados.