Después de una interesante discusión producida ayer en twitter y en la lista de agile-spain sobre la estimación en puntos de historia, he estado dándole vueltas al tema y me da la sensación de que es algo que mucha gente cuando empieza con Scrum no tiene demasiado claro. Lo viví en primera persona cuando me tocó supervisar la implantación de Scrum en mi última empresa, llegando incluso a tener discusiones grandes sobre porqué debíamos estimar así y no cómo se había hecho “toda la vida”… Así que me he decidido a aportar mi granito de arena y tratar de explicar de manera sencilla en qué consiste esto de los puntos de historia y qué beneficios aporta.
Antes de empezar, simplemente explicar, para quien no lo sepa, que los puntos de historia es la medida de estimación utilizada cuando se trabaja con Historias de Usuario, una de las técnicas mas utilizadas al trabajar con la metodología Scrum.
Relatividad
En primer lugar los PH son relativos no absolutos. Es decir estimamos en función de la diferencia relativa entre una historia y otra. Si a una historia le damos 1PH, y a otra 3PH, esto únicamente indica que una es el triple que la otra. ¿Pero el triple de qué? Pues eso lo veremos después. Además, la relatividad se aplica entre diferentes equipos, es decir que 3PH para un equipo no tienen que significar lo mismo para otro equipo (aunque trabajen en el mismo proyecto, no importa!!)
De ahí viene el utilizar la famosa escala de 0, 1, 2, 3, 5, 8, 13, 40.., ya que lo que interesa no es el valor absoluto, únicamente el orden de magnitud, además de que nos ayuda a evitar la tentación de estimar hasta el más mínimo detalle: ¿Que importancia tiene estimar 40 o 42? Cuanto mas grande es la historia a estimar, menos certeza y precisión tenemos sobre la misma, con lo cual la escala nos ayuda a ser conscientes de esa imprecisión.
Tamaño
Cuando se estima en puntos de historia, lo que se intenta es dar un valor del TAMAÑO de la historia. ¿Y qué implica Tamaño? Pues yo entiendo que una combinación de:
- Complejidad: No es lo mismo implementar una alta en un formulario que, por ejemplo, un algoritmo de inteligencia artificial para un juego
- Esfuerzo: ¿Es una tarea que tengo que repetir en muchos sitios? ¿Me va a llevar mucho tiempo aunque sea una cosa fácil?
- Riesgo: ¿Estamos trabajando con una tecnología desconocida? ¿Tiene la gente del equipo experiencia en el negocio?
Utilizando cómo métrica el tamaño, sacamos al tiempo de la ecuación, de manera que evitamos la tentación de buscar conflictos del tipo “esta historia debería estar hecha en 3 días, y tu llevas 4”, o cosas de este estilo que suelen aparecer cuando se utiliza la métrica del tiempo.
Entonces, alguien se preguntará, ¿cómo les decimos a nuestros clientes cuando tenemos listo el producto? Eso lo vamos a ver en el siguiente apartado.
Velocidad
La velocidad es el factor que nos sirve para ver cuanto trabajo somos capaces de entregar en cada sprint. Si nuestra velocidad son 15PH, estamos diciendo que entregamos 15PH de media en cada iteración. Con esto conseguimos ese factor de conversión de los puntos de historia a fechas, es la manera que tenemos de poder decirle a nuestro cliente cuando estimamos que nuestro producto estará listo (ojo, es una estimación, no hay que caer en el típico error de considerar que las estimaciones son contratos!!)
Hay que tener cuidado con esto, ya que se puede caer en la tentación de hacer cuentas y empezar a pensar en tiempo en lugar de estimaciones (1 tío 8 horas = 1PH). Esto aunque en media sea cierto no lo va a ser para todas las historias, e incluso es posible que haya historias de 1 punto, que por ejemplo se tarden mas en hacer que una de dos puntos. Por suerte, la velocidad actúa también cómo factor de corrección y a la larga, todas las historias que estén estimadas con los mismos PH van a caer mas o menos en la misma zona (la distribución aproximada debería tener forma de campana de Gauss)
Tareas
Conviene aclarar que lo que he dicho hasta ahora se refiere a la estimación de historias, no a la de las tareas en las que descomponemos dicha historia durante la planificación de Sprint. No es el objetivo de este post entrar en este tema, así que sólo diré que mi recomendación para la estimación de tareas es:
- No estimarlas
- O dividir la historia en tareas que ocupen aproximadamente un día
En Conclusión…
- Los puntos de historia permiten abstraernos del tiempo a la hora de realizar estimaciones, de manera que podemos centrarnos en aspectos cómo la complejidad o el riesgo de la historia, y valorarla en función de eso.
- Al indicar el tamaño relativo de una historia respecto a otra, es sencillo realizar estimaciones triangulando, con lo cual el proceso,con el tiempo, se vuelve muy eficiente.
- Los PH evitan la especificación al detalle, poniendo de manifiesto el aumento de incertidumbre de una especificación a medida que esta aumenta.
- La velocidad actúa cómo factor de corrección de las desviaciones en las estimaciones y nos permite realizar la conversión a fechas para poder dar plazos de entrega a nuestros clientes o superiores cuando sea necesario.
A partir de aquí lo que toca es experimentar y probar,e intentar encontrar la medida de estimación que mejor se adapte a nuestro equipo, aunque yo sin duda recomiendo encarecidamente probar con los PH!
Ya sabéis, cualquier comentario será bienvenido!!