Cómo estimar los puntos de historia para mejorar la planificación con la metodología Agile

Si alguna vez condujiste en Los Ángeles, sabes que la cantidad de tiempo que tardas en llegar de Arcadia a Santa Mónica está sujeta a una serie de factores como el tránsito, el clima, las obras, la hora del día y los caprichos de otros conductores. Es una distancia de 50 km que puede llevar 41 minutos o 4 horas. 

Dentro de la metodología Scrum, los elementos del backlog de tu producto están sujetos a un número similar de variables, lo que, a menudo, hace que la planificación Agile sea tan frustrante como estar en medio del tránsito del sur de California.

Y eso es un gran problema. Si no estimas de forma precisa y consistente el tiempo o la velocidad durante la planificación Agile, puede ocurrir que haya plazos no cumplidos, cuellos de botella, obstáculos, aumentos del alcance e incluso, a veces, que un proyecto fracase. 

La buena noticia es que hay una forma mejor de estimar el tiempo que lleva la planificación Agile: la estimación de los puntos de historia.

Desventajas de otros métodos de estimación del tiempo en proyectos con la metodología Agile

Antes de entrar en el valor de la estimación de puntos de historia, consideremos otros métodos de cálculo de tiempo utilizados en la planificación Agile.

Muchos equipos asignan una estimación por hora a proyectos y elementos, y luego asignan un número total de horas por sprint. Pero, volviendo a la analogía de conducir un vehículo, esta práctica es similar a solo observar la distancia y no tener en cuenta otros factores. 

Otra forma de estimar es la técnica del "día ideal". Cada día de trabajo incluye correos electrónicos, charlas y reuniones, lo que significa que tus desarrolladores no van a estar disponibles para trabajar durante 8 horas cada día, aunque sigan en el trabajo. La desventaja de este método de cálculo es que sigue basándose en las horas y no en el esfuerzo.

¿Qué son los puntos de historia? 

Entonces, ¿por qué la estimación de puntos de historia le da a tu equipo una idea más precisa del tiempo que tardan las historias de usuario en completarse?

Con los puntos de historia, los equipos tienen en cuenta el esfuerzo y la complejidad al asignar un valor numérico a cada elemento del backlog del producto. Los puntos de historia son mucho más completos que mirar solo un factor (el tiempo) para estimar la planificación de sprints. 

La estimación de los puntos de la historia incluye tres componentes principales:

• Riesgo: el riesgo de un proyecto o elemento en particular incluye demandas vagas, la dependencia de un tercero o cambios a mitad de tarea.
• Complejidad: este componente está determinado por lo difícil que es desarrollar la función.
• Repetición: este componente se determina por qué tan familiarizado está el miembro del equipo con la función y por qué tan monótonas son ciertas tareas dentro del desarrollo.

Al incorporar esos tres componentes, tu equipo puede planificar con mayor precisión los sprints, incluir un margen para la incertidumbre, estimar mejor los problemas y evitar apoyarse demasiado en los compromisos de tiempo. Los puntos de historia permiten la coherencia no solo a nivel de equipo, sino en todos los departamentos. 

Tres pasos para la estimación de puntos de historia en la metodología Agile

Sigue este proceso para planificar con mayor precisión tus sprints, ofrecer expectativas realistas e impulsar proyectos más rápido.

1. Utilizar los números de la sucesión de Fibonacci

Es tentador asignar elementos con una escala lineal, pero esos valores no están lo suficientemente diferenciados como para definir claramente una estimación. 

Es probable que te hayas encontrado con esto en una consulta con el médico ante una escala de dolor. Si en la escala del dolor, 1 representa "totalmente bien" y 10 es tan grave que parece que te estás muriendo, ¿qué es 4? Y, además, ¿en qué se diferencia 4 de 5? ¿Y dónde encaja un cálculo renal en la escala si nunca antes has experimentado dolor intenso?

Los números de la sucesión de Fibonacci eliminan esos saltos pequeños. Como recordarás, es una serie de números en la que cada número es la suma de los dos anteriores: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.

En la metodología Agile, la sucesión generalmente se modifica a 0.5, 1, 2, 3, 5, 8, 13, etc. Utilizando estos números, es mucho más fácil decidir si algo significa 3 puntos de historia o 5 puntos de historia. 

2. Determinar una matriz

Después de haber decidido usar la sucesión de Fibonacci, es hora de determinar una referencia para cada punto de historia. Por ejemplo:

1 = agregar un nuevo producto a un menú

2 = agregar el seguimiento de pedidos para usuarios que han iniciado sesión

3 = agregar un sistema de calificaciones al sitio web

5 = agregar un foro al sitio

8 = agregar el cumplimiento del RGPD y la ley CCPA en todo el sitio

La referencia se incluye en esta matriz como 1, que establece el estándar para lo que se ve como la menor cantidad de riesgo, complejidad y repetición en la práctica. Esta matriz es una forma de medir el esfuerzo de forma más concreta. Tenla en cuenta en lugar de juzgar los elementos basándote únicamente en la duración.

3. Hacer una ronda de Planning Poker

El Planning Poker ayuda a un equipo a obtener un consenso sobre la estimación de puntos de historia correcta para cada elemento. Así es como funciona:

1. En una reunión de planificación de sprint, cada desarrollador y evaluador recibe un conjunto de tarjetas, cada una de las cuales representa un número de la sucesión de Fibonacci.
2. Se pone sobre la mesa un elemento del backlog para que el equipo pueda hacer preguntas y aclarar las funciones.
3. Cuando se cierra el debate, cada desarrollador y cada evaluador selecciona en privado la tarjeta que refleja con mayor precisión su estimación.
4. Cuando se han seleccionado todas las tarjetas, los estimadores muestran sus tarjetas al mismo tiempo. Si se llega a un consenso, es momento de pasar al siguiente elemento del backlog. Si las estimaciones varían, los líderes debaten hasta llegar a un consenso.

Es útil tener una matriz completa a mano para que los estimadores la consulten durante el Planning Poker, ya que permite una mayor coherencia entre las tareas. Además, es útil establecer un límite máximo (13, por ejemplo). Si se estima que una tarea sobrepasa ese límite, se debe dividir en elementos más pequeños. Del mismo modo, si una tarea es menor que 1, se debe incorporar a otra tarea.

En este punto, dentro de tu reunión de planificación de sprint, los elementos del backlog del producto se pueden priorizar y dividir entre el equipo en función de la capacidad de carga de trabajo de cada integrante.

Cómo estimar la velocidad del sprint

En este punto, puedes preguntarte cuántos puntos de historia puede completar un equipo durante un sprint. Esa cantidad se llama "velocidad del sprint" y, lamentablemente, no hay manera de determinarlo hasta que no se haya completado el primero.

Durante el primer sprint después de la primera reunión de planificación de puntos de historia, lleva la cuenta de cuántos puntos de historia se completaron. Ese número total puede utilizarse para determinar una cantidad razonable de puntos de historia que tu equipo puede completar durante un sprint. Luego, podrás estimar cuántos ciclos de sprint habrá que completar para un proyecto.

Si estás usando un scrum o un tablero Kanban, solo mira la columna "Listo" al final de tu sprint y suma los puntos de historia. Con el tiempo, puedes promediar los datos de varias semanas para estimar una velocidad de sprint más precisa.

Continúa mejorando en función de las estimaciones de sprints anteriores

El primer sprint después de implementar la técnica de punto de historia no va a salir a la perfección. Y eso es completamente normal. Establece esa expectativa con tu equipo al principio para que la frustración no afecte el proceso. 

En la siguiente reunión de planificación del sprint, pregúntale a tu equipo qué ha ido bien, qué ha ido mal y qué se puede hacer para mejorar. Es posible que tengas que ajustar la matriz inicial para estimar mejor los elementos en el futuro, y puedes seguir haciéndolo hasta que tu equipo se sienta más cómodo estimando el esfuerzo de cada tarea.

Dado que el desarrollo con la metodología Agile es un esfuerzo de equipo, es importante apoyarse en los comentarios de todos para determinar las mejoras. Aunque asignar puntos de historia puede no parecer tan intuitivo como simplemente asignar estimaciones de horas a cada tarea, descubrirás que, al estimar el esfuerzo en lugar del tiempo, tendrás un sprint más tranquilo, un equipo más organizado y preparado y una experiencia general con menos estrés para cada sprint. Además, podrás conversar sobre las expectativas con las partes interesadas y establecer fechas de entrega más razonables en el futuro, lo que mejora la eficiencia y, en última instancia, el producto.