Planificación de sprint que sí termina a tiempo: dos equipos, dos resultados
La Guía Scrum le da a la Planificación del Sprint tres temas que responder: por qué es valioso este sprint, qué se puede hacer y cómo se realizará el trabajo. Bastante simple. Sin embargo, dos equipos que usan el mismo marco pueden terminar un sprint en lugares completamente distintos: uno con un incremento funcional y un objetivo del sprint cumplido, el otro con tickets a medio terminar que pasan a la próxima vez. La diferencia rara vez es el marco. Es cómo el equipo usa el evento de planificación. Imagine dos equipos, de ocho personas cada uno, ambos saliendo de un 2022 de tropiezos de suministro y un ritmo mitad remoto, mitad en oficina tras el regreso presencial.
El equipo que se desborda
El equipo A trata la planificación como una ceremonia para cargar la cola. El patrón es conocido y garantiza en silencio el desbordamiento del que se queja cada dos semanas.
No hay objetivo del sprint, solo una lista. Sin objetivo, nada se puede recortar bajo presión porque todo parece igualmente obligatorio.
El Product Backlog llega sin refinar, así que la planificación se gasta descifrando requisitos en lugar de decidir el alcance.
Se ignora la capacidad. El equipo toma la misma cantidad de elementos del sprint anterior aunque dos personas están de vacaciones y una está medio asignada a soporte.
El «terminado» es difuso. Nadie confirma qué significa finalizar, así que las pruebas y la revisión se descubren tarde y se cuentan como problema del próximo sprint.
Las dependencias —una pieza de un proveedor, una aprobación externa— se notan a mitad del sprint en vez de sacarse a la luz mientras el plan aún es maleable.
El equipo A está ocupado todo el sprint y aun así falla. Confunde actividad con progreso y, como no había objetivo, no hay nada a lo que decir que no cuando la realidad irrumpe.
El equipo que aterriza el sprint
El equipo B trata la planificación como un pronóstico que pretende cumplir. Hacen el mismo evento, en la misma hora, pero con hábitos más afilados.
Fije primero el objetivo del sprint. El Product Owner trae un único objetivo concreto que el incremento debe lograr. El objetivo se vuelve el filtro de decisión: todo lo que no lo sirva es candidato a aplazarse.
Planifique según la capacidad real, no el conteo del sprint pasado. Reste las vacaciones, la rotación de soporte, las reuniones. Los Developers toman solo lo que de verdad creen que pueden terminar, y son ellos quienes deciden: la selección es suya, no del Product Owner.
Refine lo justo antes, no durante. Gracias al refinamiento continuo, los primeros elementos del backlog ya son pequeños, claros y estimados a grandes rasgos; la planificación trata del compromiso, no del descubrimiento.
Descomponga en un plan real para los primeros días. El equipo divide los elementos principales en tareas que puede empezar de inmediato. No necesita cada detalle de todo el sprint, pero los primeros días son concretos.
Aplique la Definición de Hecho a cada elemento. Las pruebas, la revisión y la integración están dentro de la estimación, no son ocurrencias tardías. Un elemento solo «entra» si el equipo cree que puede quedar realmente Hecho, no solo programado.
Cuando algo se atrasa a mitad del sprint —una pieza llega tarde, una dependencia se estanca— el equipo B renegocia el alcance contra el objetivo del sprint con el Product Owner y aun así entrega algo valioso. El equipo A simplemente arrastra el trabajo sin terminar y lo llama velocidad. El marco era idéntico; la disciplina no. Si sus sprints se desbordan de forma habitual, la solución casi nunca es trabajar más duro durante el sprint: es planificar un pronóstico que de verdad pueda respaldar, anclado a un objetivo que esté dispuesto a proteger.
Si sus sprints siguen desbordándose y quiere una planificación que se sostenga, la asesoría de XNM en entrega de programas y proyectos puede ayudar a sus equipos a planificar hacia un objetivo y a entregarlo.