Fundamentos de Scrum Framework: ¿Cómo planificar un Sprint? + Infografía | Autor: Alonso Álvarez | Ilustraciones de Patricia Parreira.

Este artículo forma parte de una serie en la que revisaremos los fundamentos de Scrum complementados con infografías que los explican. 

Puedes consultar los artículos sobre la el Sprint, Retrospectiva, Review y Daily.

Hay bastantes concepciones equivocadas y malentendidos con Agile. Por ejemplo: “en Agile no se documenta”, “un MVP es un producto completo” o “si somos ágiles, no planificamos”. Esta última nace de retorcer uno de los valores del Manifiesto Ágil, el que dice: 

Respuesta ante el cambio sobre seguir un plan ​

Pero un poco más abajo se recuerda que: “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”. Es decir, que seguir un plan tiene valor, aunque lo tiene más responder ante el cambio. De aquí a “no planificar” hay un abismo ya que, en realidad, en los marcos ágiles se dedica bastante tiempo y esfuerzo a la planificación, siendo conscientes de que el principio director de todo es la flexibilidad (que es lo que significa “ágil” en este contexto). 

Scrum cumple con esa premisa. Aunque ofrece medios para responder eficazmente a los cambios que surjan durante la actividad, le da tanta importancia a la planificación que es uno de los pocos eventos que define, y al que dedica más tiempo. 

Planificar para orientar el Sprint

Ya hemos visto que el Sprint es ”el latido del corazón de Scrum, donde las ideas se convierten en valor”. Para reducir al mínimo la incertidumbre y dar relevancia a la creación de valor, Scrum define una serie de reuniones o eventos fijos que ocurren en un momento predecible y cuya mecánica es conocida. La planificación es el evento que marca el inicio del Sprint. 

Para la cada vez más simplificada Guía Scrum el evento de Planificación o Planning sirve para “establecer el trabajo que realizará para el Sprint”. El plan que se elabora es el resultado de un trabajo colaborativo de todo el equipo Scrum y no una idea magistral de una única persona. Todo el equipo participa activamente y por ese motivo es asumido y no impuesto.

De este evento se sale con un objetivo para el Sprint, que guía el trabajo de todos. Es la meta hacia la que se dirigen los esfuerzos, el propósito que orienta al equipo durante el Sprint y la forma de transmitir cuál será el valor aportado. 

Desarrollo del evento de Planificación

A la Planificación o Planning asiste todo el equipo. Con respecto al tiempo, sólo se indica que “tiene una duración máxima de ocho horas para un Sprint de un mes. Para sprints más cortos, el evento suele ser más corto.” Aunque sea muy tentador hacer una fácil regla de tres entre semanas de duración y horas de evento, no tiene porqué ser necesariamente así.  

Pese a que es frecuente escuchar que es una reunión “muy larga”, hay que entender que hay que dar la importancia que requiere el planificar el trabajo que se realizará durante todo el Sprint por parte de un colectivo de hasta 10 personas. En el peor de los casos, estamos hablando de dedicar el 5% del tiempo del Sprint a prepararlo adecuadamente. Escatimar aquí lleva a moverse a ciegas en el trabajo, a reuniones diarias interminables, y, aunque parezca contradictorio, a perder la capacidad de adaptación al no tener un plan adecuado por el que guiarse. 

3 conceptos clave en el Sprint

La Guía Scrum nos dice que hay que tratar tres temas principales en el evento: 

¿Qué valor aporta el Sprint? 

¿Qué se puede hacer en el Sprint? 

¿Cómo se realizará el trabajo? 

Pero no hay más indicaciones sobre cómo realizarlo. La Guía deja mucha libertad a cada equipo.  

Tradicionalmente, la planificación se dividía en dos partes: una para definir el alcance del Sprint desde el punto de vista de negocio, y otra para hacer un análisis detallado desde un punto de vista técnico. Pero el desarrollo de la sesión no tiene porqué ser necesariamente así. Lo importante es no perder de vista su objetivo y terminar con una respuesta a los tres temas planteados.  

1. Valor

A la primera pregunta se responde con el objetivo del Sprint (o Sprint Goal). El objetivo da un propósito, una guía única compartida que es un motivador intrínseco para el equipo. 

El objetivo no se define necesariamente de antemano, aunque el Product Owner (o PO) puede hacer una primera propuesta de cómo aportar valor en el Sprint. A lo largo de la sesión, el equipo en su conjunto acabará dando respuesta a esta cuestión y la materializará en el objetivo del Sprint. 

2. Alcance

La segunda pregunta “¿Qué se puede hacer en el Sprint?” requiere que PO y Desarrolladores dialoguen para seleccionar los elementos del Product Backlog que se quieren abordar durante el Sprint. Si es preciso, habrá que refinarlos para obtener más información sobre su naturaleza e implicaciones y así afinar en la planificación. 

La pregunta crítica aquí es “¿Cuántos elementos se pueden abordar en el Sprint?”. Hay numerosas técnicas de estimación, pero Scrum deja libertad para usar la más apropiada. Lo que es indudable es que la experiencia ganada en Sprints previos ayudará a afinar la estimación. 

3. Plan

La tercera pregunta requiere elaborar un plan de trabajo. Para llegar a él será necesario dividir los elementos del Backlog en unidades más pequeñas, idealmente que requieran un día de trabajo o menos. Los Desarrolladores, como expertos en el dominio de conocimiento del trabajo, son los indicados para definir cómo convertir los elementos que definen el alcance en valor final. 

Las “responsabilidades” en la Planificación

Como hemos dicho, a la Planificación asiste todo el equipo: PO, Scrum Master (o SM), y los Desarrolladores (llamados así aunque la actividad no tenga que ver con el software). Además podrían participar otras personas que aporten conocimiento experto. 

El PO tiene un papel destacado ya que es quien plantea la primera aproximación del objetivo, quien aporta el punto de vista del Negocio en representación de los stakeholders, quien tiene la potestad de priorizar y es, en definitiva, la persona con la que negocia el equipo el alcance y plan. 

Esto requiere un diálogo fluido entre PO y Desarrolladores, en un entorno seguro que permita hacer un diálogo constructivo con libertad para plantear propuestas y visiones alternativas.  

Durante la planificación suele aflorar la tensión natural entre el deseo de entregar más por parte de PO (voz de Negocio) y la realidad de la capacidad del equipo, su contexto, las incógnitas, la historia, o la deuda acumulada en el trabajo. Hacer que el proceso sea productivo, fluido y sin fricción está en manos de todos, pero especialmente del tercer invitado: el Scrum Master.

El resultado final de la actividad de Planificación es el Sprint Backlog que contiene los elementos seleccionados para ser traducidos en valor durante el Sprint. Pero no solo eso, en el Sprint Backlog tendremos también como resultado el Objetivo del Sprint, y el plan que permitirá llegar a él. 

Tras la planificación arranca el Sprint en sí, en el que se desarrolla el trabajo colaborativo del conjunto del equipo que permitirá alcanzar el Objetivo que entre todos han fijado. 

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals