Una planificación de sprint que sí termina a tiempo: seis trampas y sus soluciones
Cuando un sprint se atrasa, la retrospectiva suele buscar la causa a mitad del sprint. Las más de las veces se decidió el primer día. La planificación del sprint es donde el equipo se compromete con lo que es alcanzable, y un plan débil casi garantiza un resultado débil por mucho que se esfuerce la gente después.
La Guía Scrum estructura la planificación del sprint en torno a tres preguntas: por qué es valioso este sprint, qué se puede hacer y cómo se realizará el trabajo. Esa estructura es sólida. Lo que falla es cómo se conduce la conversación. A principios de 2021, con tantos equipos recién dispersos en oficinas en casa, la sala también se había vuelto virtual, y los malos hábitos de abajo empeoraron notablemente.
Las trampas en las que caen los equipos
Planificar sin un Objetivo del Sprint. Una lista de elementos no es un objetivo. Sin una meta única y coherente, el equipo no puede hacer concesiones a mitad de sprint, y cada elemento parece igual de obligatorio. Defina primero el porqué; le da al equipo algo con qué orientarse.
Incorporar elementos sin refinar. Si el equipo debate qué significa siquiera un elemento del Product Backlog durante la planificación, no estaba listo. El refinamiento es trabajo continuo, no una actividad del día de planificación. Los elementos no listos se inflan y rompen el pronóstico.
Tratar la capacidad como una semana completa. La gente toma días libres, asiste a reuniones y atiende soporte. Un equipo que planifica como si todos programaran cuarenta horas se sobrecompromete en cada sprint. Planifique contra el tiempo realmente disponible.
Dejar que el gerente fije el alcance. Los Desarrolladores deciden cuánto pueden asumir; eso es medular en Scrum. Cuando el alcance se dicta desde fuera, el pronóstico deja de serlo y se vuelve un deseo, y la responsabilidad se evapora en silencio.
Sin plan para los primeros días. El «cómo» importa. Los equipos que salen de la planificación sin al menos descomponer los primeros elementos en un camino claro de trabajo suelen perder los días iniciales averiguando por dónde empezar.
Confundir el pronóstico con un contrato. El Sprint Backlog es un pronóstico que los Desarrolladores refinan a lo largo del sprint. Tratarlo como una promesa fija desalienta la replanificación honesta que mantiene alcanzable el Objetivo del Sprint.
Planificar un sprint que se sostiene
Una buena planificación empieza antes de la reunión. El Product Backlog debe estar lo bastante refinado para que los elementos de arriba sean claros, pequeños y comprendidos a grandes rasgos. Así la conversación puede gastar su energía en el objetivo y el enfoque, y no en aclaraciones básicas.
Acuerden primero el Objetivo del Sprint y luego seleccionen los elementos que lo sirven. El objetivo es el ancla; los elementos del backlog son cómo se llega allí.
Pronostiquen contra la capacidad real, no contra personas por horas. Resten ausencias, reuniones y la carga recurrente de soporte.
Descompongan al menos los primeros días de trabajo para que el equipo arranque de inmediato, sin buscar.
Dejen holgura. Un plan sin margen no absorbe ninguna sorpresa, y las sorpresas están garantizadas.
Recuerden el tiempo asignado. La planificación del sprint tiene un tope de ocho horas para un sprint de un mes, y proporcionalmente menos para los más cortos. El límite es una virtud: obliga al equipo a decidir en vez de pulir en exceso el plan. Si la planificación se excede de forma habitual, la causa casi siempre es un backlog mal refinado aguas arriba, no falta de tiempo de reunión.
Un buen plan no predice el futuro a la perfección. Le da al equipo un objetivo claro, una carga realista y un arranque concreto, de modo que cuando la realidad irrumpa, y lo hará, el equipo pueda ajustarse sin perder el hilo.
Si sus sprints se atrasan pese a contar con gente trabajadora, la palanca suele estar aguas arriba, en cómo se planifica y pronostica el trabajo. La asesoría en ejecución de programas y proyectos de XNM puede ayudar a sus equipos a planificar sprints que terminan lo que empiezan.