Es un método que se desarrolló no para obtener un valor en horas del esfuerzo que se requiere para completar una historia de usuario, en realidad se utiliza para dimensionar y relacionar la complejidad de una historia de usuario con respecto a otras.
Donde el primer paso a realizar es seleccionar una historia de usuario para asignarle una complejidad nominal sirviendo de referencia para poder catalogar al resto de historias, es decir tiene una línea base para comenzar a comparar entre ellas la complejidad, esta línea base siempre deberá de ser realizada por el equipo.Es muy importante comentarles que los valores que se utilizan para la representación de la complejidad no tienen un valor absoluto sino que su valor es basado en la función de su posición en la escala.
Las historias de usuario se basaron en la sucesión de Fibonacci: 1,2,3,5,8,13,21, 34, 55 etc, pero debido a que el pensamiento se basa en precisión matemática de la numeración, los valores fueron sustituidos por otros aproximados:0,1,2 3,5,8,13,40,100, también lo que se puede realizar es utilizar otros valores que ayudan a dimensionar el tamaño como son la medidas de la playeras como pueden ser XS, S, M, L, XL.
Los puntos de historia, nunca se deben de considerar o comparar con horas de esfuerzo, ya que la realidad es que son utilizadas para catalogar la dificultad de la tarea que se realizaran, es importante mencionar que el número de horas que nos lleve realizar alguna de nuestras historias dependerá de la capacitación y capacidad de la persona que la lleven a cabo,otro factor importante a considera es la carga de trabajo del equipo es por eso importante mencionar que tiene posibilidades de variar dichos valores dependiendo de la situación en la que se encuentre el equipo.
Al momento de cambiar de las gestiones tradicionales a la agilidad choca mucho l pensamiento con este tipo de estimación, derivado a que la estimación no es absoluta si no relativa 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 muy diferente. Inclusive es necesario destacar que nunca podremos 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 cosas completamente diferentes, ya que cada proyecto tiene sus bemoles.
En los marcos de trabajo agiles, se realiza una selección de cuantos puntos de historia se podrán entregar en la siguiente iteración, es decir cuántas historias de usuario se pueden implementar en función de varias situaciones como son la productividad, carga de trabajo y factores alrededor del equipo.
Una de la técnicas más ocupadas es el Planning Poker , la cual se basa en el consenso y diferentes formas de pensar del equipo, donde el Scrum master es responsable de llevar la reunión, a continuación les detallo el flujo de la misma:
El desarrollador con más conocimientos de la característica que se revisara menciona una breve descripción de la misma, el Team es responsable de hacer preguntas y discutir acerca de las respuestas para aclarar los supuestos y mitigar los riesgos. Cada uno de los integrantes del Team tiene un mazo de cartas con los valores que decidieron utilizar, por lo que deberán de seleccionar una tarjeta y colocarla boca abajo la cual representa su estimación, los valores en ningún momento deben ser mencionados, posteriormente el Team al mismo tiempo destape las tarjetas y las personas con estimaciones más alta y más baja deberán de justificar el porqué de esa estimación, donde todo el team comparte su perspectiva, este proceso se repite hasta que se alcance un consenso, en mi particular experiencia con máximo realizar tres votaciones es más que suficiente para llegar al consenso, de no ser así debemos de revisar si cumple el Definition of ready la historia que estamos dimensionando, ya que pueden existir muchas dudas acerca de lo que se realizara y es por eso que no se llega a un acuerdo.
Así que a seguir haciendo agile en su día a día.
Scrum está Pelón , donde solo importa compartir experiencias 