La reunión de planificación del sprint, paso a paso

La planificación del sprint es la reunión con la que se inicia un sprint. En ella, el equipo acuerda un objetivo del sprint y decide qué parte del backlog puede completar de forma realista, convirtiendo así una lista priorizada en un plan en el que el equipo realmente cree. Un backlog es una lista de deseos hasta que alguien decide qué se va a desarrollar a continuación. Esa decisión es la planificación del sprint.

Si se hace bien, lleva una o dos horas y el equipo sale de allí sabiendo qué tiene que hacer y por qué. Si se hace mal, se convierte en una sesión de lectura de la lista de tareas pendientes en la que el responsable de producto asigna tickets y todo el mundo asiente con la cabeza —y el «compromiso» se desmorona silenciosamente para el miércoles.

Por qué, qué y cómo

La Guía de Scrum estructura la planificación del sprint en torno a tres preguntas, y conviene mantenerlas en este orden:

• ¿Por qué es valioso este sprint? La respuesta es el objetivo del sprint: una frase en torno a la cual todo el equipo pueda unirse. Acuerden este objetivo antes de abordar la lista de tareas pendientes. Establecer un objetivo de sprint es una habilidad en sí misma.
• ¿Qué se puede hacer en este sprint? Los desarrolladores seleccionan tareas de la parte superior de la lista de tareas pendientes que contribuyen al objetivo, hasta que alcanzan el límite de su capacidad. Se trata de una previsión, no de una promesa hecha bajo juramento.
• ¿Cómo se llevará a cabo el trabajo seleccionado? El equipo desglosa los elementos prioritarios en un plan lo suficientemente detallado como para poder empezar: tareas, enfoque y riesgos evidentes. No se desglosa cada elemento hasta la última subtarea, sino lo suficiente para comenzar con confianza.

El resultado es un backlog del sprint: el objetivo, los elementos seleccionados y el plan para su entrega.

Primero, definir el alcance; después, elaborar el plan

El hábito estructural más útil es llevar a cabo la planificación en dos fases bien diferenciadas, en lugar de una sola fase poco definida.

La primera parte se centra en el alcance. El responsable del producto presenta el objetivo y los elementos candidatos por orden de prioridad. El equipo formula preguntas para aclarar dudas, comprueba que cada elemento cumpla con la definición de «listo» y selecciona trabajo hasta agotar su capacidad. Deténgase ahí. La tentación de incluir «solo una más» historia pequeña es precisamente lo que provoca que los sprints se sobrecarguen.

La segunda parte consiste en la planificación. Ahora el equipo analiza en profundidad los elementos que ha seleccionado: los desglosa en tareas, identifica las dependencias y acuerda quién se encargará de qué en primer lugar. Es aquí donde se descubre que esa historia que parecía un «3» es, en realidad, una semana de trabajo oculta tras un criterio de aceptación impreciso.

Mantener ambas cuestiones separadas evita que la reunión se convierta en un debate sin fin entre «¿deberíamos incluir esto?» y «¿cómo lo haríamos?» con respecto a cada uno de los puntos.

Lo que necesita en la habitación

La planificación del sprint solo funciona si los datos de entrada llegan ya preparados. La reunión convierte esos datos en un plan; no los elabora sobre la marcha.

• Una lista de tareas pendientes refinada y priorizada. Los elementos principales ya deberían estar bien entendidos y tener una estimación aproximada de su volumen. Si la reunión de planificación es la primera vez que el equipo ve una historia, está realizando el refinamiento de la lista de tareas pendientes en la reunión equivocada, y esta se alargará más de lo previsto. El refinamiento es la fase preparatoria; la planificación es la toma de decisiones.
• Una cifra real de capacidad. No «dos semanas multiplicadas por el tamaño del equipo», sino las horas realmente disponibles tras descontar las bajas, las reuniones, las rotaciones de apoyo y el tiempo perdido por interrupciones. Véase planificación de la velocidad y la capacidad.
• Todo el equipo. Los desarrolladores son quienes elaboran la previsión, por lo que deben estar presentes. La planificación a través de terceros da lugar a compromisos de los que nadie se hace responsable.

¿Quién lo dirige?

El Scrum Master actúa como facilitador: vela por el cumplimiento del plazo, mantiene separadas las dos fases y evita que la reunión derive en la búsqueda de soluciones para cada caso extremo. El product owner aporta el objetivo y la lista de tareas ordenada, y responde sobre la marcha a las preguntas «por qué» y «qué». Los desarrolladores deciden qué volumen de trabajo asumen y cómo lo van a desarrollar.

Este último punto es importante: la previsión es responsabilidad de quienes realizan el trabajo. Un plan impuesto y aceptado en silencio no es un compromiso, sino una simple indicación.

Cuánto tiempo debería tardar

La Guía de Scrum establece un tiempo máximo de ocho horas para la planificación de un sprint de un mes, y proporcionalmente menos para los sprints más cortos, lo que supone aproximadamente dos horas por semana de sprint. Un sprint de dos semanas debería rondar las cuatro horas, aunque a menudo es menos una vez que el equipo ha alcanzado un ritmo constante.

Considérelo un límite máximo, no un objetivo. Los equipos que necesitan utilizar todo el tiempo asignado casi siempre están perfeccionando el plan durante la reunión de planificación. Si se ajustan los datos de entrada, la reunión se acortará por sí sola. Si desea un desglose minuto a minuto, el capítulo «Orden del día de la planificación del sprint» ofrece uno.

Dónde se comete el error

La mayoría de las reuniones de planificación fallidas se deben a tres tipos de fallos.

La sesión de lectura. El responsable de producto expone las incidencias y el equipo escucha. No se toma ninguna decisión porque nadie está decidiendo; simplemente se les está informando. La planificación debería dar la sensación de que es el equipo el que elige, y no de que se le asignan tareas.

El exceso de compromiso. La capacidad se trata como un objetivo ambicioso. El equipo toma su mejor ritmo de trabajo como mínimo y añade un poco más por ambición. Entonces, un problema de soporte, una baja por enfermedad y una historia subestimada convierten el sprint en una carrera contrarreloj. Planifique con una cifra modesta, no con una heroica.

Planificar sin un objetivo. El equipo selecciona un conjunto variopinto de tickets sin relación entre sí y, cuando el sprint se complica, no hay ningún criterio para decidir qué descartar, por lo que todo se retrasa un poco y nada se entrega en perfectas condiciones. El objetivo es lo que le indica qué tickets debe descartar bajo presión.

Prepare los datos de entrada, mantenga separados el alcance y el plan, y deje que el equipo se haga cargo de la previsión. El resto de esta guía profundiza en cada uno de estos aspectos: comience por la agenda o descargue la plantilla de planificación del sprint.

Preguntas frecuentes

¿En qué consiste la planificación de un sprint?

La planificación del sprint es el evento de Scrum que da inicio a un sprint. El equipo acuerda el objetivo del sprint, selecciona los elementos del backlog que prevé poder completar y esboza cómo se llevará a cabo el trabajo. En él se responden tres preguntas: por qué el sprint es valioso, qué se va a desarrollar y cómo.

¿Cuánto tiempo debería durar la reunión de planificación del sprint?

Fije un plazo de aproximadamente dos horas por semana de sprint —es decir, unas dos horas para un sprint de una semana, cuatro para uno de dos semanas y hasta ocho para uno de un mes—. Se trata de un límite máximo, no de un objetivo. Si necesita constantemente el plazo completo, lo más probable es que la lista de tareas pendientes no estuviera preparada desde el principio.

¿Cuáles son los pasos clave en la planificación de un sprint?

Confirme la capacidad real del equipo para el sprint; acuerde un objetivo para el sprint; seleccione elementos del backlog que contribuyan a ese objetivo hasta alcanzar la capacidad máxima; desglose los elementos principales en un plan viable; y confirme que el equipo está de acuerdo con la previsión. Primero el alcance, luego el plan: en ese orden.

¿Quién dirige la reunión de planificación del sprint?

El Scrum Master actúa como facilitador y se encarga de que se respeten los plazos. El Product Owner aporta una lista de tareas pendientes priorizada y depurada, y explica los motivos. Los desarrolladores deciden cuánto pueden asumir y cómo lo van a desarrollar: la previsión es responsabilidad suya, no una tarea que deba asignar el Product Owner.