La petrificación de la planificación

---

¿Están predeterminados los resultados de su planificación de Sprint? ¿La reunión parece formulada? ¿O simplemente francamente aburrido? Si es así, su equipo ha llegado a lo que yo llamo la 'Petrificación Planificada'. La reunión ha llegado a un punto en el que la flexibilidad y creatividad que se ofrece a través de ella se ha visto disminuida. Está petrificado. Puede que incluso haya llegado al punto de impactar negativamente al equipo… ¡pero no todo está perdido! Si la formación del Sprint Backlog se ha convertido en un escenario para que su equipo "apruebe" un conjunto rígido de requisitos, entonces dudo que estén avanzando hacia convertirse en un equipo autoorganizado. Tan pronto como dejaron de considerar el Sprint Backlog como una unidad de trabajo cohesiva, el incremento resultante probablemente será percibido como "pequeño", es decir, sin valor. Hay belleza que ver en la reunión de planificación del Sprint, sólo necesitas saber cómo revelarla.

Fundamentalmente, el propósito de Sprint Planning es producir dos cosas. En primer lugar, un Sprint Goal: el propósito unificado de todo el incremento. Es la portería hacia la que el equipo debería avanzar. Debe ser mensurable, alcanzable, fijo y, lo que es más importante, permitir la creatividad en cómo se logra. En segundo lugar, el Sprint Backlog en sí: el trabajo probable necesario para lograr el objetivo. Tenga en cuenta que utilicé la palabra "probable": un malentendido común en Scrum es que el equipo se está comprometiendo a "terminar" el Sprint Backlog. De hecho, se comprometen a lograr el objetivo del Sprint. Esta es una distinción importante: el equipo puede adaptar su enfoque en función de su inspección del progreso (¿Le suena algo 'Responder al cambio en lugar de seguir un plan'?).

Aquí tienes una técnica que te propongo que pruebes. Trabaja para construir la autoorganización, la creatividad y centrarse en el propósito colectivo. Es importante destacar que requiere confianza.

Supongamos que todo el equipo Scrum está presente y que usted tiene una cartera de productos bien ordenada que el equipo ha ido perfeccionando con el tiempo. El Product Owner sabe lo que quiere lograr.

Paso 1: Deseche el Product Backlog (metafóricamente). Informe al equipo que no utilizará el Product Backlog para impulsar la reunión de planificación.

Paso 2: Pídale al Product Owner que defina claramente el valor que desea del próximo Sprint (específicamente sin referirse a tickets).

Paso 3: El equipo de desarrollo, en colaboración con el propietario del producto, define tickets y criterios de aceptación para el trabajo inicial hacia el objetivo del Sprint. Todavía no están mirando el Product Backlog.

¿Qué se consigue con este enfoque? Estás quitando la muleta del Product Backlog. Consideran el trabajo planificado como un incremento formado y no como una colección de tickets individuales. Están colaborando y no despidiendose. Tienen el poder de ser creativos y comprometerse. En resumen, aceptan el valor del Sprint Goal. Sin embargo, recuerde siempre volver a visitar el Product Backlog al final de la sesión para revisar su enfoque; no olvide que sigue siendo el artefacto principal que impulsa el evento.

Para mí, aunque la Revisión del Sprint es donde se mide el progreso general, lo que me encanta es la reunión de Planificación. ¿Por qué? Porque es el punto en el que puedo ver lo entusiasmado que está mi equipo por el próximo desafío. Después de todo, si no tienen el fuego en el estómago en la línea de salida, ¿cómo crees que se sentirán en la línea de meta cuando ni siquiera querían estar en la carrera?

Etiquetas: melé