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 no es más que una lista de deseos hasta que alguien decide qué se va a desarrollar a continuación. Esa decisión se toma en la planificación del sprint.

Si se hace bien, dura 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 todos asienten 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 está en el objetivo del sprint: una frase en torno a la cual todo el equipo pueda unirse. Pónganse de acuerdo al respecto 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 empezar: tareas, enfoque y riesgos evidentes. No se desglosa cada elemento hasta la última subtarea; basta con lo necesario para comenzar con confianza.

El resultado es una lista de tareas pendientes del sprint: el objetivo, las tareas seleccionadas y el plan para llevarlas a cabo.

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

El hábito estructural más útil, sin duda, consiste en llevar a cabo la planificación en dos fases bien diferenciadas, en lugar de una sola que resulte imprecisa.

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, desglosándolos en tareas, identificando las dependencias y acordando 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 ambos aspectos separados evita que la reunión se convierta en un debate interminable 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 crea sobre la marcha.

• Una lista de tareas pendientes refinada y priorizada. Las tareas principales ya deberían estar bien entendidas y tener una estimación aproximada de su volumen. Si la 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á demasiado. El refinamiento es la fase preparatoria; la planificación es la fase de 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 genera 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 cuánto trabajo asumen y cómo lo van a desarrollar.

Este último punto es importante: la previsión corresponde a quienes realizan el trabajo. Un plan impuesto y aceptado en silencio no es un compromiso. Es una simple espera.

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 invariablemente todo el tiempo asignado casi siempre se dedican a perfeccionar 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, en el capítulo «Orden del día de la planificación del sprint» encontrará uno.

Dónde se comete el error

Hay tres motivos que explican la mayoría de las reuniones de planificación fallidas.

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 asignen 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 de contrarreloj. Planifique con una cifra modesta, no con una heroica.

Planificar sin un objetivo. El equipo selecciona una mezcla heterogénea 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. Empiece por la agenda o utilice 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 un objetivo del sprint, selecciona los elementos del backlog que prevé poder completar y esboza cómo se llevará a cabo el trabajo. En este evento 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, más o menos 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 todo el tiempo asignado, 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 propietario del producto aporta una lista de tareas pendientes priorizada y depurada, y explica los motivos. Los desarrolladores deciden cuánto trabajo pueden asumir y cómo lo van a desarrollar: la previsión es responsabilidad suya, no una tarea que deba asignar el propietario del producto.