cómo estimar los puntos de la historia para una planificación ágil mejorada

si alguna vez ha experimentado tráfico en Los Ángeles, sabe que la cantidad de tiempo que debe tomar para llegar de Arcadia a Santa Mónica está sujeta a una serie de fuerzas que incluyen tráfico, clima, construcción, hora del día y los caprichos de otros conductores. Es una distancia de 32 millas que podría tomar 41 minutos o 4 horas.,

los elementos en su backlog de productos Scrum están sujetos a un número similar de variables, lo que a menudo hace que la planificación ágil sea tan frustrante como sentarse en el tráfico del Sur de California.

Y eso es un problema masivo. Si no puede estimar de manera precisa y consistente el tiempo o la velocidad durante la planificación ágil, puede provocar plazos fallidos, cuellos de botella, obstáculos, pérdida de alcance y, a veces, incluso el fracaso de un proyecto.

la buena noticia es que hay una mejor manera de estimar el tiempo que lleva la planificación ágil: la estimación de puntos de la historia.,

desventajas de otros métodos de estimación de tiempo en proyectos ágiles

antes de entrar en el valor de la estimación de puntos de la historia, consideremos otros métodos de estimación de tiempo utilizados en la planificación ágil.

muchos equipos asignan una estimación a los proyectos y artículos por hora, y luego asignan un número total de horas por sprint. Pero, si volvemos a la analogía de conducción, esta práctica es similar a solo mirar la distancia al conducir y no tener en cuenta otros factores.

otra forma de estimar es la técnica del «día ideal»., Cada día de trabajo consiste en correos electrónicos, chats y reuniones, lo que significa que sus desarrolladores no estarán disponibles para trabajar durante 8 horas todos los días, aunque todavía estén en el trabajo. La desventaja de este método de estimación es que todavía se basa en horas, No esfuerzo.

¿qué son los puntos de la historia?

entonces, ¿cómo la estimación de puntos de historia le da a su equipo una estimación más precisa del tiempo que tardarán en completarse las historias de los usuarios?

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

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

  • riesgo: el riesgo de un proyecto o elemento en particular incluye demandas vagas, dependencia de un tercero o cambios a mitad de la tarea.
  • complejidad: este componente está determinado por lo difícil que es desarrollar la característica.
  • repetición: este componente está determinado por lo familiarizado que está el miembro del equipo con la función y por lo monótonas que son ciertas tareas en desarrollo.,

al incorporar los tres puntos anteriores, tu equipo puede planificar sprints con mayor precisión, incluir un colchón para la incertidumbre, estimar mejor los problemas y evitar inclinarse demasiado en los compromisos de tiempo. Los puntos de historia permiten la consistencia no solo en los equipos, sino en todos los departamentos.

3 pasos para una estimación ágil de puntos de la historia

Siga este proceso para planificar con mayor precisión sus sprints, ofrecer expectativas realistas y acelerar los proyectos.,

Use números de secuencia de Fibonacci

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

es probable que haya encontrado esto en el consultorio del médico con una escala de dolor. Si 1 en la escala de dolor representa «totalmente bien» y 10 es un dolor tan severo que se siente como si pudiera estar 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 has experimentado dolor intenso antes?

Los números de secuencia de Fibonacci eliminan esos saltos menores., Como recordarán, la secuencia de Fibonacci es una serie de números donde cada número es la suma de los dos números anteriores: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.

para Agile, la secuencia se modifica típicamente a 0.5, 1, 2, 3, 5, 8, 13, etc. Usando estos números, es mucho más fácil decidir si un artículo tiene 3 puntos de historia o 5 puntos de historia.,

Fibonacci scale example (Click on image to modify online)

Determine a matrix

After you’ve decided to use the Fibonacci sequence, it’s time to determine a baseline for each story point., Por ejemplo:

1 = Agregar un nuevo producto a un menú desplegable

2 = Agregar seguimiento de pedidos para usuarios registrados

3 = Agregar un sistema de calificaciones al sitio web

5 = Agregar un foro al sitio

8 = agregar el cumplimiento de GDPR y CCPA en todo el sitio

Su línea de base se incluye en esta matriz como 1, que establece el estándar de cómo se ve la menor cantidad de riesgo, complejidad y repetición en la práctica. Esta matriz es una manera más concreta de medir el esfuerzo; tenga esto en cuenta en lugar de no juzgar los elementos basándose solo en el tiempo.,

realizar una ronda de planning poker

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

  1. en una reunión de planificación de sprint, cada desarrollador y probador recibe un conjunto de tarjetas, cada una que representa un número de una secuencia de Fibonacci.
  2. un elemento de backlog se lleva a la mesa para que el equipo pueda hacer preguntas y aclarar características.
  3. cuando se cierra la discusión, cada desarrollador y probador selecciona en privado la tarjeta que refleja con mayor precisión su estimación.,
  4. Cuando todas las cartas han sido seleccionadas, los estimadores revelan sus cartas al mismo tiempo. Si se alcanza un consenso, es hora de pasar al siguiente ítem de backlog. Si las estimaciones varían, los líderes discuten hasta llegar a un consenso.

es útil tener una matriz completa a mano para que los estimadores hagan referencia durante la planificación del poker, ya que permite una mayor consistencia entre las tareas. Además, es útil establecer un límite máximo (13, por ejemplo). Si se estima que una tarea es mayor que ese límite, debe dividirse en elementos más pequeños., Del mismo modo, si una tarea es menor que 1, debe incorporarse a otra tarea.

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

cómo estimar la velocidad de sprint

en este punto, puede que te estés preguntando cuántos puntos de historia puede completar un equipo durante un sprint. Esa cantidad se llama velocidad de sprint, y desafortunadamente, no hay manera de determinar eso hasta que se haya completado el primer sprint.,

durante el primer sprint después de su primera reunión de planificación de puntos de historia, lleve un registro de cuántos puntos de historia se completaron. Ese número total se puede usar para determinar un número razonable de puntos de historia que tu equipo puede completar durante un sprint. Luego, podrás estimar cuántos ciclos de sprint se necesitarán completar para un proyecto.

si estás usando un tablero Scrum o Kanban, simplemente mira la columna «hecho» al final de tu sprint y suma el número de puntos de la historia. Con el tiempo, puede promediar varias semanas de datos para estimar una velocidad de sprint más precisa.,

Detailed Scrum task board example (Click on image to modify online)
Kanban board with prioritization example (Click on image to modify online)

Continue to improve based on past sprint estimates

The first sprint after adapting the story point technique is not going to go perfectly. And that’s completely normal., Establezca esa expectativa con su equipo al principio para que la frustración no secuestre el proceso.

en la próxima reunión de planificación de sprint, pregúntale a tu equipo qué salió bien, qué salió mal y qué se puede hacer para mejorar. Es posible que deba ajustar su matriz inicial para estimar mejor los elementos en el futuro. Y esa matriz puede ajustarse hasta que su equipo se sienta más cómodo con la estimación del esfuerzo de cada tarea.

dado que el desarrollo ágil es un esfuerzo de equipo, es importante apoyarse en gran medida en los comentarios del equipo para determinar la mejora., Si bien los puntos de la historia pueden no parecer tan intuitivos 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 menos estresante para cada sprint. Además, podrá discutir 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, mejora el producto.,

ahora que ha estimado todos los puntos de su historia, el siguiente paso es crear su plan de lanzamiento ágil.

más información

Author: admin

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *