Una lista de verificación para planificar un sprint que sí termine a tiempo
La planificación de sprint es el momento en que un equipo Scrum se compromete con un plan realista para las próximas semanas. Cuando sale mal, los síntomas son conocidos: una reunión de dos horas que se vuelve de cuatro, un Sprint Backlog en el que nadie cree del todo y un sprint que se desborda en silencio. La Guía Scrum asigna a la planificación tres temas a resolver — por qué el sprint es valioso, qué se puede hacer y cómo se realizará el trabajo —, pero no te da la disciplina para resolverlos rápido. Esa parte le corresponde al equipo.
A mediados de 2021, con muchos equipos aún trabajando en remoto o en repartos híbridos incómodos y con problemas de suministro que ponían nerviosas las fechas de entrega, el costo de un plan descuidado subió. Un plan hecho a través de tres husos horarios y una videollamada inestable debe ser más ajustado, no más laxo. La lista de abajo está pensada para usarse la misma semana en que la leas.
Antes de la reunión
La mayor parte del dolor en la planificación lo causa trabajo que el equipo debió hacer antes. El refinamiento no es parte de la planificación; es una actividad continua que la acorta. Repasa esto el día anterior:
El Product Owner tiene un objetivo de producto claro y un Product Backlog ordenado, con los primeros elementos refinados lo suficiente para empezar.
Los elementos probables de la cima son pequeños — cada uno cabe con holgura en un sprint.
Cada elemento candidato tiene criterios de aceptación que los desarrolladores realmente leyeron, no ojearon cinco minutos antes.
Conoces tu capacidad real: quién está ausente, quién es de tiempo parcial en este equipo, qué feriados o guardias caen en el sprint.
Toda dependencia entre equipos tiene un responsable con nombre y una fecha, no una suposición optimista.
Durante la reunión
Mantén los tres temas en orden y resiste el impulso de diseñar todo el sistema. El objetivo es un plan suficientemente bueno para empezar, no un plan que sobreviva intacto al contacto con la realidad.
Nombra primero el objetivo del sprint. Acuerda una frase que describa por qué importa este sprint antes de elegir un solo elemento. El objetivo es el compromiso; los elementos se negocian alrededor de él.
Tira, no empujes. Los desarrolladores eligen cuánto trabajo asumen. El Product Owner aclara prioridad y concesiones, pero no asigna la carga.
Planifica sobre la capacidad real. Usa la velocidad o el rendimiento como referencia y luego resta ausencias, reuniones y carga de soporte. Un plan basado en una semana perfecta es un plan que falla.
Descompón lo justo para empezar. Divide los primeros elementos en trabajo que los desarrolladores entiendan. No necesitas todas las tareas de la semana dos — solo un camino creíble hacia el día uno.
Haz una prueba de confianza. Pregunta a cada desarrollador cuánta confianza tiene en que el objetivo es alcanzable. Si el ánimo es tibio, recorta el alcance ahora, no en el día ocho.
Antes de cerrar
No dejes que la reunión se detenga sola. Ciérrala de forma deliberada para que todos salgan con la misma imagen: el objetivo del sprint está escrito donde el equipo lo ve, el Sprint Backlog refleja lo realmente acordado, las dependencias y riesgos están registrados con responsables, y alguien ha dicho en voz alta: «Sí, creemos que podemos terminar esto». Para un equipo remoto, ese artefacto compartido importa más que nunca — es la fuente única de verdad cuando nadie está en la misma sala. Si la planificación sigue siendo larga tras varios sprints, la causa casi siempre está aguas arriba: un backlog mal refinado. Corrige eso y la planificación se acortará por sí sola.
Cuando la presión de entrega es alta y el plan debe sostenerse, la asesoría en entrega de programas y proyectos de XNM ayuda a los equipos a planificar un trabajo que sí pueden terminar.