¿Cuándo se estiman los Story Points y la prioridad en la fase de planificación de Agile?

En nuestras sesiones de recopilación de requisitos ágiles (no estoy seguro del nombre técnico, lo siento), donde interactuamos con el propietario del producto para enumerar todas las historias que se requieren para la implementación, generalmente estimamos los puntos de la historia y la prioridad a medida que avanzamos.

¿Es esta la metodología correcta ? Y además, ¿es el más efectivo? ¿O deberíamos enumerar todas nuestras historias de usuarios, luego retroceder y priorizar y estimar SP?

Respuestas (1)

La estimación y priorización de puntos de historia es un proceso continuo en Agile.

Lo más importante es tener estimaciones de puntos de historia y priorización hechas para el trabajo que el equipo está a punto de hacer. Por lo general, esto sería de 1 a 4 semanas de trabajo pendiente. Es menos importante hacer estimaciones y priorizar historias que están más lejos en el futuro.

Eso no quiere decir que haya ningún daño en estimar y priorizar con anticipación, solo que siempre debemos permitir la posibilidad de cambio. Por lo tanto, las estimaciones a largo plazo y la priorización deben tratarse como probables de cambiar .

Un enfoque común es el siguiente:

  • El equipo comienza a reunir los requisitos. Se enfocan en el trabajo que es probable que hagan primero, quizás de 1 a 4 semanas de requisitos.
  • El equipo prioriza y hace estimaciones puntuales de la historia para el trabajo que están a punto de comenzar.
  • El equipo comienza a trabajar.
  • A medida que el equipo trabaja, se dan algo de tiempo para refinar su acumulación de requisitos. Por ejemplo, en Scrum usamos del 5 al 10 % del tiempo del equipo en refinar el backlog.
  • Cuando el equipo refina el backlog, a menudo hará más estimaciones y priorizaciones de puntos de historia.

Piense en ello como una canalización de requisitos. El equipo está trabajando en los requisitos de mayor prioridad y, al mismo tiempo, está planificando el próximo conjunto de requisitos que realizarán. La ventaja de este enfoque es que es muy fácil adaptarse al cambio. Si los requisitos o las prioridades cambian, es fácil que el equipo se adapte, ya que no están demasiado adelantados en su planificación.

Hay algunas situaciones en las que el equipo puede querer hacer estimaciones de puntos de la historia y priorizar más en el futuro (digamos uno o dos meses antes). Los equipos a menudo hacen planes de lanzamiento cuando quieren centrarse en un hito particular de la funcionalidad. El equipo conoce aproximadamente la velocidad a la que avanzan en las historias (es decir, conocen su velocidad en puntos de historia por iteración) y, por lo tanto, al estimar más adelante el trabajo pendiente, pueden calcular aproximadamente dónde estarán en el futuro.

Es importante que estos planes a más largo plazo no se consideren inamovibles. Debido a que el enfoque ágil enfatiza la adaptación al cambio, anticipamos que el cambio ocurrirá. Por lo tanto, generalmente adaptaremos continuamente nuestros planes a mediano y largo plazo a medida que avanzamos.