Es el evento o ceremonia Scrum que da comienzo al Sprint. Su propósito es la creación de un Objetivo para el Sprint, así como la selección de aquellos elementos del Product Backlog y concepción del plan de trabajo que permitirán conseguir aquel.
Tiene un timebox o duración máxima de ocho horaspara un Sprint de un mes; suele durar menos si el Sprint es más corto.
El Product Owner ha de asegurarse de que los asistentes están listos para abordar los elementos más importantes del Product Backlog, es decir, debe llevar un Product Backlog ordenado según prioridad.
Será muy recomendable que los elementos del Product Backlog más importantes tengan el detalle suficiente para que los Desarrolladores los puedan seleccionar y llevar al Sprint Backlog. Esto requiere haber realizado el correspondiente refinamiento previo.
El Equipo Scrum puede invitar a terceros para que asistan y aconsejen durante la Planning. Por ejemplo, puede ser conveniente la presencia de especialistas en determinadas áreas, internos o externos a la empresa.
La Sprint Planning contempla 3 temas diferenciados.
1/ ¿Por qué debemos hacer este Sprint?
2/ ¿Qué puede entregarse como Incremento Terminado?
3/ ¿Cómo haremos el trabajo necesario para entregar el Incremento?
1/ La Sprint Planning interminable. Si la primera vez que los Desarrolladores ven los elementos del Product Backlog que el Product Owner propone es en la Sprint Planning, mal vamos. El resultado suele ser una reunión infinita y soporífera. Los Desarrolladores intentan entender los elementos, el propio Product Owner se desdice constantemente y tampoco lo tiene del todo claro, y así pasan los minutos y las horas. El Equipo se queda atascado en el qué y no consigue tratar el cómo.
Esto, además, significa empezar el Sprint con el pie cambiado. Los Desarrolladores intentarán clarificar los elementos del Product Backlog durante el Sprint, hablando con el Product Owner y stakeholders a ser posible, sin poder avanzar con el trabajo de implementación, o haciéndolo lentamente. En estas condiciones, entregar un Incremento al final del Sprint será todo un milagro.
Hacemos aquí n par de consideraciones como respuesta a la Sprint Planning “interminable”:
– El antídoto frente a este tipo de situaciones se llama “hacer los deberes” o, lo que es lo mismo, hacer refinamiento del Product Backlog. El Scrum Master puede facilitar que Product Owner y Desarrolladores celebren sesiones de refinamiento, en las que, colaborativamente, añadir detalles y estimaciones a los elementos del Product Backlog, dividirlos en otros más pequeños cuando sea necesario, hablar sobre cómo será la implementación, etcétera. Lo que queremos es que los elementos del Product Backlog estén “ready” para ser seleccionados.
– En todo caso, el Product Owner es el responsable de la gestión del Product Backlog, y esto implica, entre otras tareas, añadir elementos, actualizarlos, ordenarlos o eliminar los que no sean relevantes, ya sea por sí mismo o por delegación en otros. Cuando el Product Owner hace dejación de esta responsabilidad, los Desarrolladores lo tendrán complicado y la Sprint Planning, casi seguro, será un desastre. En estos casos, el Scrum Master ha de trabajar con el Product Owner y ensenarle técnicas para la gestión efectiva del Product Backlog.
2/ El Equipo Scrum termina la Sprint Planning sin haber creado un Objetivo del Sprint o Sprint Goal, o con uno manifiestamente inadecuado. En estos casos, el Scrum Master debe ayudar a que el Equipo colabore y cree conjuntamente este Sprint Goal -lo conveniente será que el Product Owner llegue a la Sprint Planning con una idea más o menos clara a este respecto, y que pueda proponerla al Equipo-. En esta otra sección explicamos qué es el Sprint Goal y para qué sirve.
3/ El Scrum Master o el Product Owner o ambos presionan a los Desarrolladores para que añadan al Sprint Backlog tantos elementos como sea posible, y exigen que los Desarrolladores se comprometan a su entrega. Este tipo de prácticas impiden que el Equipo Scrum funcione de manera autogestionada y minarán su moral.
El compromiso en Scrum significa dar lo mejor de nosotros mismos para conseguir el Objetivo del Sprint, que justamente nos da flexibilidad respecto al alcance concreto que se implemente. Permitamos, por favor, que sean los Desarrolladores quienes hagan la selección de elementos del Product Backlog en los que trabajarán durante el Sprint, y que sean también los Desarrolladores quienes decidan cómo se asignan las tareas de implementación, a fin de conseguir dicho Objetivo.
Evitemos ser el Product Owner que impone el alcance como si fuera una suerte de “todo o nada”, no negociable, o el típico Scrum Master “sargento” que asigna las tareas al resto. El Sprint Backlog es un artefacto que solo pertenece a los Desarrolladores, y que, aunque se empieza a crear en la Sprint Planning, será modificado a lo largo del Sprint, conforme los Desarrolladores aprenden más y más sobre el trabajo que están acometiendo.
4/ La deuda técnica es ignorada. Cuando los elementos del Product Backlog seleccionados tocan áreas de la aplicación cuyo código es frágil, lo correcto será computar tiempo para reparar esa deuda técnica, en lugar de seguir añadiendo nueva funcionalidad sobre un código ya deficiente. Sin embargo, a menudo habrá presión para entregar la funcionalidad cuanto antes, a expensas de su calidad técnica. Esto es “pan para hoy y hambre para mañana”. Aseguremos que el plan del Sprint incluye actividades de pair-programming, automatización de tests y refactorización, antes de que sea demasiado tarde.