¿Vale la pena identificar Tasks en el Iteration Planning?

¿Vale la pena identificar las Tasks?

Recientemente he escrito mucho sobre identificar tasks en el Iteration Planning. Se trataba de ayudar al equipo a identificar la cantidad y el tamaño correctos de tasks.

Para la mayoría de los equipos, la respuesta es: Sí.

No encuentro la lista de tasks en sí particularmente útil. Sin embargo, el hecho de que uno tenga que pensar en la creación de la lista es extremadamente útil.

Un ejemplo de una buena lista de tasks

Supongamos que estás planeando un hermoso viaje a la ciudad y ahora quieres empacar tu maleta. Entonces creas una lista de empaque o simplemente comienzas a tirar ropa en tu maleta. Pensarías hasta cierto punto en lo que necesitarás. Pero también sabes que si olvidaste algo, en caso de necesidad también podrías comprarlo en el lugar.

Sin embargo, sería diferente si hubieras planeado una expedición al Monte Everest. En este caso, pensarías más cuidadosamente en lo que necesitarás. A más de 8.800 m de altura será difícil comprar algo que olvidaste. Por lo tanto, en este caso definitivamente escribirías una lista de empaque y probablemente la revisarías dos o tres veces.

¿Pero esta lista de empaque también te es útil durante el ascenso al Monte Everest?

Para nada.

Pero el hecho de que hayas pensado intensamente en ello, sí.

El valor real de identificar tasks

Lo mismo se aplica a identificar tasks en el Iteration Planning. Solo pensar en estas tasks ya es el valor agregado, y no necesariamente la lista en sí.

Todo en la lista de tasks teóricamente también podría haberse identificado en tiempo real diariamente durante la iteración. Sin embargo, identificar tasks tan tarde puede llevar a problemas de coordinación y retrasos. Si sé que necesito algo de alguien la próxima semana, esa persona puede pensar cuándo completará esta tarea. Si necesito algo de alguien inmediatamente y no puedo continuar antes de que esta tarea esté completa, esa persona no tiene el lujo de poder decidir cuándo lo hará. Debe trabajar en ello ahora, porque estoy esperando.

¿Debería tu equipo identificar tasks en el Iteration Planning o no?

Básicamente: Sí. Creo que un equipo puede dejar de identificar tasks tan pronto como dominen lo siguiente:

Colaboración durante la iteración para trabajar a través de los elementos recién descubiertos.
Saben cuántos (y cuáles) Product Backlog Items deberían incluir en la iteración.
En mi opinión, los equipos deberían identificar tasks hasta que alcancen este punto. Pero por favor recuerda identificar solo aproximadamente dos tercios de todas las tasks de la iteración. Esa es una buena guía para pensar en lo que debe hacerse sin sobrepensar todo.

Esto es comparable a planificar la expedición al Monte Everest y saber que al menos puedes comprar algunos últimos suministros en Katmandú.

El problema de la identificación de tasks

Hay dos problemas cuando los equipos quieren identificar cada task individual en el Iteration Planning:

1. Es casi imposible querer identificar todo excepto las cosas más obvias. No importa cuánto esfuerzo haga tu equipo, nunca lograrán pensar en todo de antemano.

2. Es demasiado trabajo.

El propósito del Iteration Planning es seleccionar los Product Backlog Items correctos, es decir, exactamente la cantidad correcta de items que son más importantes para la entrega.

Un equipo puede hacer todo esto sin tener que pensar en cada pequeño detalle que debe completarse en esta iteración. Siempre que los miembros del equipo piensen en las cosas más importantes, también pueden seleccionar la cantidad correcta de Product Backlog Items correctos.

Los miembros del equipo deben pensar en lo siguiente:

• Tasks grandes
• Tasks que requieren mucha coordinación, ya sea entre los miembros individuales del equipo o entre miembros del equipo y personas fuera del equipo
• Tasks que muy probablemente pertenecen a la ruta crítica
• Las tasks originales o principales de los Product Backlog Items donde todavía hay mucha incertidumbre

Aparte de estos puntos, realmente no necesitas pensar en nada más. Eso sería solo una gran pérdida de tiempo y llevaría a que los miembros del equipo ya no quieran participar en las reuniones más importantes, ya que están hartos.

Lo que un buen Scrum Master o Agile Coach puede hacer

Durante algunas iteraciones, no deberías hacer cambios, excepto contar las tasks identificadas en el Iteration Planning. Luego cuentas las tasks que existen al final de la iteración. Debes contar todas las tasks, incluso las que aún no se han completado o iniciado.

Después de hacer esto durante una o dos iteraciones, se calcula el porcentaje de tasks que el equipo identificó en la reunión de planificación.

Un ejemplo:

Supongamos que un equipo ha completado tres iteraciones. En la primera iteración, el equipo identificó 50 tasks en la reunión de planificación y al final de la iteración había un total de 60 tasks en el Iteration Backlog. Eso significa que durante el curso de la iteración se agregaron 10 tasks.

En la segunda iteración, el equipo identificó 45 de 60 tasks en la reunión de planificación. Y en la última iteración, 55 de un total de 70 tasks.

Eso significa que el equipo identificó 50 + 45 + 55 de un total de 60 + 60 + 70 tasks en las reuniones de planificación. Eso son 150 de un total de 180 tasks. El equipo identificó así el 83% de todas las tasks durante las tres reuniones de planificación.

Eso es demasiado.

Por experiencia y después de realizar esta medición con muchos equipos, puedo decir que los equipos ágiles exitosos identifican aproximadamente dos tercios de todas las tasks en la planificación.

Si tu equipo identifica más de estos dos tercios en las reuniones (como el equipo en el ejemplo anterior), entonces tu equipo probablemente está pasando demasiado tiempo en la reunión de Iteration Planning.

Explica esto a tu equipo en la próxima reunión de Iteration Planning y felicita a los miembros del equipo por haberse esforzado tanto con la planificación. Luego diles que reducirás el tiempo en 30 minutos.

Sin embargo, si el porcentaje de tu equipo está por debajo del 67%, comparte esta información también con los miembros del equipo y diles que tanto el equipo como tú mismo se beneficiarán de proceder un poco más a fondo en la planificación. Luego agrega 30 minutos al tiempo de planificación.

Repite esto hasta que tu equipo identifique aproximadamente dos tercios de todas las tasks en la reunión de planificación. Y una vez más, no digo que debas simplemente terminar la discusión en un límite mágico. Úsalo simplemente como una guía práctica para pasar la cantidad correcta de tiempo en las reuniones de Iteration Planning.

Quiero señalar una vez más que estoy hablando de dos tercios de las tasks de un equipo. Eso definitivamente será más que dos tercios del tiempo planificado de una reunión de Iteration Planning. Las tasks que no se identifican en la reunión de planificación suelen ser las tasks más pequeñas.

Aprende más sobre el apoyo en la planificación o el refinement en nuestro training certificado de Scrum Master. Si ayudas a tu equipo a identificar solo aproximadamente dos tercios de las tasks de una iteración, ayudarás a tu equipo a tener éxito con Agile.