Método de Estimación Ágil: Puntos de Historia

Las metodologías ágiles han cambiado muchos conceptos en el desarrollo del software, entre ellos la forma de realizar estimaciones. Veamos cómo estimar utilizando el método de puntos de historia.

El método de puntos de historia se desarrolló no para obtener un valor en horas de esfuerzo para el desarrollo de una historia de usuario (cada una de las parte en que se divide la funcionalidad a desarrollar en las metodologías ágiles) sino como una manera de dimensionar y relacionar la complejidad de las historias de usuario con respecto a otras.

Como primer paso del proceso, se selecciona una historia de usuario para asignarle una complejidad nominal que servirá de referencia para catalogar al resto de historias de usuario: como esta historia es de complejidad X esta otra, que en comparación es menos compleja, será de complejidad i, donde i es menor que X ó como esta historia es más compleja será de complejidad j, donde j es mayor que X.

Los valores que se utilizan para representar la complejidad no tienen un valor absoluto sino que su valor es función de su posición en escala.

Se comenzó utilizando la serie de Fibonacci: 1,2,3,5,8,13,21, …, aunque para evitar que se pensara que hay una precisión matemática en los valores a partir de cierto número se sustituyeron por otros aproximados: 3,5,8,13,40,100,… (el 1 y el 2 no se recomienda utilizarlos al no incluir mucha diferencia con respecto al 3).
También se puede utilizar los siguientes valores: Extra Small, Small, Medium, Large, Extra Large.

Como el método se basa en la comparación de historias de usuario ya realizadas se necesita contar con una línea base de historias realizadas por el equipo.

La complejidad de las historias, los puntos de historia, no se pueden comparar a horas de esfuerzo ya que el sentido que tienen es catalogar la dificultad de la tarea. El número de horas que nos lleve realizarlas dependerá de la capacitación y/o capacidad de la persona que la lleve a cabo, la carga de trabajo del equipo, etc. y por ello variará dicho valor dependiendo de la situación.

El principal problema que supone la utilización de los puntos de historia es que son relativos a cada equipo de desarrollo y por ello no podemos comparar los puntos de historia medidos por un equipo con los de otros equipos ya que la utilización de los valores puede ser diferente. Es más, tampoco podemos hacer comparaciones de la velocidad de desarrollo de cada uno de los equipos por el número de puntos de historia que hayan implementado ya que podemos estar comparando naranjas con manzanas.

En una planificación siguiendo metodología ágil, se seleccionan cuantos puntos de historia se podrán entregar en la siguiente iteración, es decir cuántas historias de usuario se podrán implementar en función de la productividad del equipo, de la carga de trabajo y del resto de factores ambientales. Con ello las tareas de planificación se simplifican y se logran valores bastantes más cercanos a la realidad.

El Planning Poker es una forma de llevar a cabo una estimación y una planificación en Agile, en el vídeo podemos entender (o no), como se realiza (o como no) una planificación ágil, utilizando los puntos de historia.


¿Crees que es útil medir la complejidad de las tareas independientemente de las horas que cuesten?