Como ya contáramos con más detalle en el libro “Cómo sobrevivir… A la planificación de un proyecto ágil” de 233 Grados de TI, si estimas usando puntos historia es muy recomendable que lo hagas usando un buen rango, si no quieres perder tiempo y acumular frustraciones.
No me voy a extender en qué son los puntos historia, ya lo hemos contado varias veces (en el anterior libro, en este post Como estimamos proyectos Scrum o en general ágiles y en este ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes)
Aún así, muy resumidamente, los puntos historia son una unidad usada, normalmente, para medir el “tamaño” de una historia de usuario. Más concretamente, un punto historia es una fusión de la cantidad de esfuerzo que supone desarrollar la historia de usuario, la complejidad de su desarrollo y el riesgo inherente (si no habías escuchado antes el término, léete mejor los post que te dejé antes o el libro).
La experiencia, y varios estudios (como este del amigo Eduardo Miranda), ha demostrado que es mejor estimar usando rangos o escalas fijas y conocidos de posibles valores que se pueden asignar a la estimación, es decir, fijando un tope máximo de puntos historia.
¿Por qué te cuento ahora todo esto? Porque me estoy encontrando últimamente con demasiada gente que está teniendo problemas en este punto. Problemas de tipo a usar un rango grandísimo de posibles puntos historia, como, por ejemplo, los enteros del 1 al 100 y entrar en debates interminables sobre si una historia debe tener 138 o 139 puntos historia. Problemas del tipo a usar los enteros del 1 al infinito, y no saber nunca cual es el número mayor que se puede asignar.
Para evitar los problemas anteriores, además de fijar un número máximo, para que todo el mundo fije en su cabeza el rango, lo “mayor” y lo “menor”, normalmente, hay dos escalas de puntos historia que suelen tener buenos resultados:
– 1, 2, 3, 5, 8, etc. (fijando un máximo, normalmente el 100)
– 1, 2, 4, 8, etc.
La primera escala es la secuencia de Fibonacci, útil porque la separación entre los números de la secuencia se hace más grande a medida que los números aumentan. En la segunda, cada número es dos veces el número que le precede.
En ambas secuencias de números no lineales funcionan bien porque reflejan mayor incertidumbre asociada a estimaciones de grandes. Y evitan discusiones eternas del tipo ¿le ponemos 78 o 79?
Toma como ejemplo, el tablero que se usa en 233 Grados de TI, y que te dejo en la siguiente imagen, donde puedes ver el rango de puntos historia que usamos.
Como puedes ver en la imagen, quitando las tres primeras cartas y la última (que creo que no las hemos usado nunca), el rango tiene un tope máximo y un total de 10 posibles valores, siendo la separación entre estos mayor según aumenta la serie.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Mi práctica es basada en analogía. En primer lugar, ninguna historia por más simple que sea se puede resolver en menos de un día. ( no se si es correcto, pero necesito una referencia temporal ). Y luego el puntaje básico es simplemente por «tamaño» del problema.
Y prefiero Fibonacci (o alguna escala no lineal). La complejiidad del código no escala lineal. Si un problema tiene el doble de componentes (clases, LOC, métodos) probablemente sea un poco más que el doble de complejo. Así, según mi referencia temporal, si me lleva un día es 2. Si intuitivamente pienso 2 días es 3. Pero como los problemas no escalan de manera lineal, si intuitivamente pienso en 3 días entonces es 5.
Obviamente si mi sprint tiene 10 o 15 días, la velocidad es de 2 puntos de historia de usuario por día.
Pero a esa estimación inicial le puedo imputar un 10% 15% 25% más por complejidad ( si las reglas de negocio son muy rebuscadas o con muchas condiciones) y un 10% 15% 20% más por riesgo (si por ejemplo tengo integración de tecnologías, o no tengo del todo claro aspectos del requerimiento por poner dos riesgos habituales).
Hago esto de que en mi equipo separemos esfuerzo por tamaño, de esfuerzo por complejidad y por riesgo, porque muchas veces cuando vemos todo junto tendemos a simplificar la complejidad o no visibilizar del todo los riesgos. De esta manera dejamos un espacio de tiempo puntual para pensar en posibles riesgos (en esta parte de nuestro trabajo surgen tareas no planeadas para el sprint, dado que muchas veces la mitigación del riesgo nos hace dar cuenta de que necesitamos algunas acciones particulares).
saludos.
Otra aclaracion ahora que releo mi comentario… si un problema es el doble de complejo, probablemente tenga más del doble de componentes (no como dije anteriormemte).
Hola Javier. ¿Que opinas de estimar en horas?
Está bien si el equipo tiene mucha experiencia, está bien a corto plazo,
Hola, muy buen post, por favor si pudieses colocar los link de los libros que comentas, en este y otro post comentas libros, pero no es posible acceder a ellos. Mil gracias 🙂
Hola Javier, en el tablero que muestras como ejemplo, tomando el rango del 1 al 100, hay algo que me causa confusión, el punto 8 se encuentra en la mitad del rango si lo consideramos por posición y no por valor, entonces 100 (que está al extremo) podría considerarse casi el doble que 8, cosa que no es así si lo tomamos numéricamente, ya que en verdad sería casi 12 veces más de su valor (casi 12 veces más complejo) . Cómo se interpretaría ya que de la mitad hacia abajo no hay mayor dispersión a comparación de la parte superior. Mi equipo trabaja con un rango lineal y cuando vimos la posibilidad de usar la serie de Fibonacci surgió esa inquietud.