5 razones para cambiar el orden de los items

Un Product Owner le entrega a su equipo 10 Story Cards (tarjetas con una User Story cada una). Los miembros del equipo las leen y le devuelven al Product Owner la quinta y la sexta tarjeta. Al final del Sprint, el equipo entrega la funcionalidad de las tarjetas 1, 2, 3, 4 y 7. Sin embargo, aún no se ha comenzado a trabajar en las tarjetas 5 y 6.

En mi opinión, eso está bien.

Una recomendación estándar en las metodologías ágiles es que el equipo debe trabajar en los items del Backlog en el orden que establece el Product Owner. Aunque esto tiene sentido hasta cierto punto, los buenos equipos ágiles hacen excepciones a esta regla con regularidad.

Hay muchas buenas razones para que un equipo no siga el orden establecido. Aquí he enumerado algunas que deberían ser suficiente justificación:

1) Efectos de sinergia

A menudo existen sinergias entre los items que están en la parte superior del Product Backlog. Mientras un equipo trabaja, por ejemplo, en el item n.º 3, también debería poder trabajar en el item n.º 6. Si dos items se encuentran en la misma parte del sistema y pueden completarse más rápido juntos, el Product Owner debería permitirlo.

2) Dependencias

Un equipo podría decidir que el item 4 es más importante que los items 5 y 6. Desafortunadamente, el n.º 4 no puede trabajarse hasta que el n.º 7 esté terminado. Una dependencia de este tipo suele ser razón suficiente para permitir que un equipo se desvíe del orden previsto.

3) Disponibilidad de conocimiento especializado

Un equipo quizás quisiera trabajar en el cuarto item más importante del Product Owner, pero la persona adecuada para ello no está disponible. Naturalmente, esto puede ser una señal de que más miembros del equipo deberían ser capaces de trabajar de forma multifuncional, pero eso es más bien una solución a largo plazo. Una solución a corto plazo sería simplemente trabajar en otros items hasta que el miembro del equipo con las habilidades necesarias vuelva a estar disponible.

4) Es más interesante

De acuerdo, este punto es discutible. No estoy diciendo que el equipo deba trabajar en los items n.º 1, 2, 3, 4 y luego en el n.º 600. Pero seleccionar los items como en mi ejemplo (1, 2, 3, 4, 7) está bien si el trabajo se vuelve un poco más emocionante de esa manera.

En algunos proyectos, los equipos ocasionalmente se encuentran con una serie de Product Backlog Items que no son realmente muy divertidos. Si un equipo puede adelantar de vez en cuando un item que ofrezca algo de variedad, esto puede tener un efecto positivo en la moral de los miembros del equipo. Y eso, a su vez, es bueno para el Product Owner.

Bonus: 4.1.) Es más interesante para los Stakeholders

Ya que estamos en el tema: también afirmo que está bien que un equipo cambie el orden si ciertos items son interesantes para los Stakeholders.

A veces puede ser todo un desafío lograr que todas las personas importantes asistan a los Sprint Reviews. Se vuelve especialmente difícil cuando los últimos Reviews fueron bastante aburridos. La razón puede ser la alta prioridad de ciertos trabajos (por ejemplo, cosas importantes que no son realmente visibles para los Stakeholders).

En un caso así, puede ser inteligente darle un poco de atractivo al próximo Sprint Review. Porque si el equipo trabaja en algo que los Stakeholders encuentran interesante, será más probable que asistan a la reunión.

5) Tamaño

Si las razones anteriores aún no le han convencido, he guardado la razón más convincente para el final. Demuestra que todo equipo puede desviarse del orden establecido por el Product Owner: un equipo puede, por ejemplo, saltarse el item n.º 5 si es demasiado grande. Entonces el equipo toma el siguiente item que quepa en el Sprint según su tamaño.

Si esto no estuviera permitido, el equipo solo seleccionaría los items 1, 2, 3 y 4 y luego se detendría. Entonces posiblemente una parte considerable del Sprint quedaría sin utilizar. Por supuesto, el equipo podría completar al menos una parte del item 5 y luego abordar otro. Pero en muchos casos eso no tiene mucho sentido. Por lo tanto, el equipo se desviará al menos de vez en cuando del orden original.

Los Product Owners no son perfectos

Un Product Owner perfecto sabría todo esto. Un Product Owner perfecto sabría que los primeros cuatro items del Backlog ya implican tanto trabajo relacionado con la base de datos que no debería poner otro item similar en la posición 5. Un Product Owner perfecto sabría que los items 2 y 5 se refieren a la misma clase Java y los agruparía al priorizar.

A la mayoría de los Product Owners les resulta difícil ser perfectos. La mejor solución es simplemente priorizar el Product Backlog lo mejor posible y luego dejar el ajuste fino al equipo.

Este texto proviene del blog de Mike Cohn y fue traducido al español.

agile100: Roger Martin

=> En febrero de 2021 hablamos con Roger L. Martin sobre su libro "When more is not Better".

Trabajo ágil en MAN

=> ¿Qué tan ágil es MAN Truck & Bus SE y cómo funciona el trabajo ágil en la industria automotriz?