En agile no estimamos adivinando el tiempo que nos va a llevar una historia de usuario. Estimamos lo gorda que es en comparación al resto. Esta estimación ágil de tamaño la hacemos comparando la historia de usuario con otras que hemos estimado e implementado antes (y por tanto conocemos su tamaño). A esto lo llamamos estimación relativa. En contraposición está la estimación absoluta de waterfall, que consiste en adivinar directamente el tiempo que vas a tardar en hacer la historia de usuario.
Qué es un punto historia
La medida que utilizamos es el punto historia o story point. Un punto historia es mezcla de:
- Complejidad: Una historia que es más compleja que otra tendrá más puntos historia.
- Esfuerzo: Quizás una historia no tiene complejidad pero si requiere esfuerzo (ejemplo, cambiar literales en todas las pantallas de la aplicación), también tendrá más puntos historia que otra más corta.
- Incertidumbre o riesgo: Es la probabilidad de que algo no esperado aparezca en la historia, siempre por falta de información previa. Aquí no se cuenta lo que suele ir mal. Por ejemplo, si cada vez que tocamos el módulo de autenticación rompemos algo, eso no debe reflejarse en la estimación (porque no queremos tapar los puntos de mejora).
Para las estimaciones en puntos historia el equipo utiliza una escala de estimación. No es más que una herramienta en forma de panel con ejemplos representativos de cada medida de estimación. Si utilizamos la escala de Fibonacci modificada de planning poker, una escala de estimación debería tener más o menos esta pinta.
Velocidad del equipo
El equipo necesitará algo más que puntos historia para planificarse las iteraciones. El Product Owner muy probablemente necesite también una estimación de coste de las historias de usuario para decidir si merece la pena invertir el coste para el beneficio que da cada historia.
Para ello contamos con la velocidad del equipo en puntos historia. Por ejemplo un equipo hace de media 50 puntos cada iteración de 2 semanas. Con esta velocidad el equipo puede coger historias estimadas en puntos y completar hasta esos 50 puntos en una sesión de planificación de iteración. El product owner puede saber incluso el coste aproximado de cada historia de usuario, ya que dividiendo la velocidad del equipo por las horas invertidas por el equipo en una iteración (si el equipo es de 5 personas: 5 personas por 10 días por 8 horas = en 400 horas haces 50 puntos, cada punto son 8 horas).
Beneficios de estimar en puntos historia
Y, ¿por qué estimar en puntos historia y no en tiempo directamente?. Hay muchas razones para hacerlo, aquí tienes 5:
- Es mucho más sencillo estimar comparando tamaños que estimar el tiempo que vas a tardar. En consecuencia las sesiones de estimación acaban antes (mucho antes si utilizas técnicas como la estimación por afinidad).
- Tienes una evolución de la mejora en el equipo. Si estimas tamaño las estimaciones se mantienen aunque el equipo mejore su rendimiento. Si estimas en tiempo directamente esa medida no la tendrás.
- Elimina el factor optimista de la mayoría de seres humanos (véase falacia de la planificación y ley de Hofstadter)
- Es más fácil estimar en grupo. Si tienes un equipo heterogeneo con distintos grados de madurez y experiencia, probablemente haya personas que tarden más que otras en hacer lo mismo. Estimando el tamaño, llegarás antes a un consenso.
- También es más fácil porque no tendrás que especular el tiempo que dedicas a reuniones, interrupciones, contratiempos, etc.
Si quieres ampliar algunos de estos puntos sobre por qué estimar en puntos historia te dejo un artículo de Javier Garzás y Noemí Garrido sobre el tema.
En definitiva, huye de las estimaciones de tiempo y no mires atrás. La estimación en puntos historia o cualquier otra medida relativa (por ejemplo ositos de goma o tallas de camiseta) te da muchos beneficios que difícilmente vas a tener con una estimación en tiempo.
¿Cuál es tu experiencia con las estimaciones? Estaré encantado de leerla en tu comentario 