La Sprint Planning es uno de los eventos de Scrum, quizás, el menos relevante en términos de adaptación pero el más importante para poder ser autogestionados. En muchos Scrum Team y empresas este evento se hace muy pesado y, en algunos casos, lo podríamos calificar de infernal. ¿Cómo podemos hacer que sea productivo?
Los componentes de la Sprint Planning
La Sprint Planning es un evento que ocurre al principio de un Sprint. Su misión es construir el Sprint Backlog que nos servirá durante el Sprint para organizar el trabajo y focalizarnos en un objetivo (Sprint Goal). Su duración es de 8 horas para Sprints de 30 días y más cortos para Sprints menos duraderos. Para este evento estará todo el Scrum Team.
Durante la Sprint Planning debemos responder a tres preguntas clave:
- ¿Por qué este Sprint aportará valor?, cuya respuesta es el Sprint Goal
- ¿Qué se puede terminar este Sprint?, cuya respuesta serán items seleccionados previstos a completar
- ¿Cómo podemos terminar el trabajo seleccionado?, cuya respuesta será un plan de trabajo
La suma del Sprint Goal, los items seleccionados y el plan de trabajo es lo que conocemos como Sprint Goal.
¿Qué debemos tener antes de la Sprint Planning?
Para garantizar que el evento es productivo debemos hacer un trabajo previo. En primer lugar, tener a las personas disponibles. He visto equipos que han hecho Sprint Plannings sin el Product Owner porque “estaba muy liado”. La conversación entre todos es esencial para alinearnos y sin eso empezaremos a dar “bandazos” durante el Sprint que va a comenzar. Podemos también necesitar a stakeholders clave para participar. ¡Cuidado! debemos evitar que participen personas que busquen más el control que aportar. Ahora bien, podemos necesitar un especialista funcional o de una tecnología para la que nos vendría bien un refuerzo.
En segundo lugar, debemos conocer nuestra capacidad para el Sprint. Vacaciones, médicos y situaciones controladas deben estar encima de la mesa de cara a saber con quién podemos contar. Obviamente, siempre pueden ocurrir imprevistos pero todo lo que podamos conocer es buen momento para sacarlo a la luz. Nos guste o no, un equipo debe conocer la parte personal de sus miembros para entender lo que nos viene encima.
Otro elemento clave es la Definition of Done. La DoD es clave en la Sprint Planning ya que tiene una incidencia directa en lo que seremos capaces de entregar. Existe una diferencia si cada feature se considerará terminadas tras tres comprobaciones de código que aquellas que se validan directamente por el Developer. Recordemos que la DoD se puede revisar en la Sprint Retrospective por lo que habrá que tener en cuenta si la hemos evolucionado.
Y por último, necesitamos el Product Backlog con elementos ready para el Sprint. Aquí es clave haber refinado estos elementos candidatos previamente. Esto es esencial porque podemos alargar innecesariamente la Sprint Planning hablando de muchos items que no están suficientemente trabajados.
Sprint Planning y estimaciones
Las estimaciones son siempre un tema que genera expectación. Por un lado, hay equipos con cierto expertise, que no necesitan estimar para entender lo que van a hacer durante el Sprint. Otros equipos lo necesitan. También, hay organizaciones que, por su cultura de control, requieren que estimemos todo.
Mi opinión es que, las estimaciones tienen dos utilidades claras. Por un lado, permiten a los Developers analizar y conversar sobre cada item, lo que nos permite entender mejor el Sprint que estamos comenzando. Por otro lado, puede ser útil para hacernos una idea de cómo será el Sprint. ¡Ahora bien! Los equipos donde el tiempo de estimación supera el 80-90% del evento para mí se están equivocando. Es más relevante hablar sobre cómo nos vamos a organizar que sobre estimaciones, entre otras cosas, porque las estimaciones son un invento que usamos.
Por último, recordemos que Scrum eliminó cualquier referencia a estimar, por lo que no es obligatorio hacerlo. Ahora bien, en el caso de que lo necesitemos, serán los Developers quienes tienen la potestad para ello.
¿Cómo hacerlo productivo?
Para conseguir una Sprint Planning productiva recomiendo varias técnicas. Para el Sprint Goal, puede ser una buena idea que el/la Product Owner nos traiga una propuesta sobre la que podamos debatir. Es esencial debatir a alto nivel la viabilidad del mismo. Una vez realizado, toca hablar del alcance y de los items que vamos a abordar. Para esta parte, ayuda mucho haberlos leído antes y, si fuera posible, haberlos refinado previamente. Un buen truco es repartirnos los items de futuros Sprints y refinarse en pareja con el Product Owner. De esta manera, evitamos tener refinamientos muy largos y, a su vez, garantizamos que parte del equipo ha trabajado esos items. ¡Todos ganamos!
Una buena técnica para garantizar que entendemos bien los items es que el Product Owner los lea tal cúal están escritos (sin aclaraciones) para saber si los Developers lo han entendido. Si el equipo hace preguntas, esas aclaraciones las debemos incorporar al item concreto. Así, evitamos que pasado un tiempo de la Planning se nos haya olvidado esos detalles.
Dónde más tiempo invertimos en la Sprint Planning es en la organización del equipo. Para esta parte recomiendo estar de pie si estamos en presencial. Si estamos de pie podemos centrarnos todos en sacar adelante el Plan de Trabajo.
Para montar el Plan recomiendo usar herramientas como Mural/Miró o un tablero de Post Its en el que pongamos todos los items que hemos seleccionado y nos dediquemos a añadir aquellas tareas necesarias para completarlos. Al añadir tareas, hablaremos sobre cada uno de ellos y cómo podemos completarlos. Si el Sprint Goal no va a llenar todo el Sprint, podemos usar colores donde se diferencia nuestro auténtico foco de otras tareas del Sprint.
Y tú, ¿cómo haces la Sprint Planning?
