Sprint Planning en remoto

Uno de los eventos clave de Scrum es la Sprint Planning. Muchas empresas piensan que una buena planificación arreglaría muchos problemas. No obstante, el verdadero motivo por el que la Sprint Planning es clave es porque los equipos autogestionados necesitan gestionarse, es decir, necesitan un espacio de reflexión sobre cómo van a trabajar las próximas semanas. En digital, al tener menos contacto físico, nos cuesta más organizarnos, por lo que deberemos añadir nuevas herramientas y técnicas que faciliten el propósito de este evento. ¡Comenzamos! 

Product Backlog y Sprint Backlog

La Sprint Planning es el momento donde creamos nuestro Sprint Backlog, como una subparte de nuestro Product Backlog. Aquí, es importante diferenciar, lo que vayamos a hacer en el Sprint lo reflejaremos en el Sprint Backlog, mientras que en el Product Backlog dispondremos de todo lo que podremos llegar a querer en nuestro producto. 

Debemos entender que funcionan de manera diferente. El Product Backlog está ordenado y debe estar, su función es marcar las prioridades, basado en los criterios que considere el Product Owner. Generalmente, buscará maximizar valor, pero también puede combinar tareas a largo plazo estratégicas con operativas cortoplacistas pero necesarias. 

El Sprint Backlog es diferente. Muchos software como Jira, tienden a tener un Sprint Backlog que es un subconjunto del Product Backlog. ¡No es cierto! Un Sprint Backlog está compuesto por tres elementos clave: PBI (elementos del Product Backlog) seleccionados para el Sprint, un Sprint Goal que marque para qué hacemos este Sprint y un plan de trabajo. 

Por tanto, construir un Sprint Backlog es algo más complicado que seleccionar varios elementos del Product Backlog (PBIs) y esperar que se hagan en el mismo orden. Recordemos que, el Product Backlog, busca maximizar valor pero el Sprint Backlog busca organización, por eso el Product Owner no debe ordenar pensando en cómo se va a construir

Reglas generales de la Sprint Planning en remoto

Una de las dificultades de la Sprint Planning es conseguir enganchar a todo el Scrum Team. Muchas veces se convierten en eventos aburridos donde solo nos dedicamos a estimar tareas o items. ¡Es mucho más que eso! Además, es el evento de mayor tiempo destinado, con hasta ocho horas para Sprints de 30 días. Para colmo, dado que muchas empresas aún mantienen la mentalidad de control, usamos este evento como una reunión de estimación y esto nos complica la gestión de la misma. Algunas reglas que debemos tener en cuenta: 

• Debe estar el Scrum Team completo
• Podemos invitar alguna persona ajena al equipo que necesitemos para alguna aclaración o algún tema concreto que se necesite trabajar
• El trabajo que se va a hacer debería estar refinado, en caso contrario, tocará hacerlo
• La herramienta que vayamos a usar debe estar disponible para todos
• Es un evento de todos, la persona que ejerce de Scrum Master puede facilitar pero sin abusar de esta regla

Objetivo de la Sprint Planning 

Este evento es útil y divertido si es dinámico. Pero para eso, necesitamos entender el verdadero objetivo del mismo. En Scrum no existe jefe, ni responsable, ni coordinador ni cualquier palabra sinónima. En Scrum apostamos por la autogestión que es diametralmente opuesta al libertinaje. La autogestión es gestión, es decir, buscamos gestionarnos a nosotros mismos, solo que no depende de una sola persona, sino de un grupo que tiene capacidad de decidir por sí mismo. 

Esto es clave, nuestro verdadero objetivo es tener un espacio de tiempo donde podamos organizarnos. Repito, el objetivo es organizarnos, no dar estimaciones a la empresa para que parezca que estamos trabajando. 

Dado que Scrum se centra en entregar valor, el objetivo de la Sprint Planning es organizarnos para poder conseguirlo. Por tanto, el objetivo no es cumplir con una estimación sino, una vez más, ¡entregar valor! Por eso dedicamos estas horas y por eso el valor debe ser el centro de la conversación. 

Ahora bien, el valor surge de la construcción de nuestro producto y ello no ha cambiado mucho, tenemos que tener unos requisitos en formas de Items de trabajo que estarán refinados y debemos desarrollar. Puede parecer similar a modelos tradicionales pero cambia bastante entendiendo que la conversación sobre el valor debe darse en cada momento. 

Un preparador físico hace el mismo trabajo tanto si entrena a una persona normal que a un deportista de élite, debe hacer seguimiento, proponer ejercicios, asegurarse que los hace bien y medir. Ahora bien, no es lo mismo hacerlo pensando que hay una competición internacional el mes que viene que con una persona que solo quiere mejorar su forma física. Que el trabajo sea el mismo se enfoca de maneras muy diferentes cuando pensamos en resultados. 

Herramientas para hacer la Sprint Planning en remoto

En primer lugar, recomiendo que herramientas tipo Jira, Kanbanize o similares, se utilicen como gestoras de producto y no de equipo. Esto para mí es clave, es ideal separar las herramientas de producto de las de organización. Las primeras nos sirven para hacer seguimiento del Producto. Las segundas nos ayudan a visualizar el estado del trabajo y poder coordinarnos sin necesidad de nadie. En presencial, solíamos usar postits, ahora tendremos que apoyarnos en herramientas tipo Mural, Miró o Jamboard. 

Desde la perspectiva de Producto, en donde necesitamos saber qué está hecho y qué no. Con que tengamos dos estados: todo y done sería suficiente. En Jira no necesitamos más detalles sobre lo que hacen las personas, precisamente porque es autogestión. En mi experiencia, cuando en una empresa le piden a los equipos que lleven todo su trabajo a Jira es porque están buscando control, falta confianza. ¡Trabajo este aspecto primero!

Sin embargo, herramientas como Mural/Miró con boards digitales, podemos visualizar rápidamente el estado del trabajo y centrarnos en cómo nos vamos a organizar. Evidentemente, tener dos herramientas puede resultar tedioso, por suerte, ambas herramientas tienen conexión con Jira. 

Cómo hacer la Sprint Planning en remoto

La primera parte que siempre recomiendo es hacer status de la situación actual. Es decir, ¿cómo vamos? ¿qué aprendimos en la Sprint Review? ¿próximos pasos? En esta parte, buscamos hablar del Product Goal, del valor que estamos aportando y de todo lo que estudiamos en la Sprint Review con los stakeholders. Por mi parte, propongo siempre que en la Sprint Review existe una parte de “digestión” de la misma, en la que el Product Backlog quede refinado con el feedback recibido. Si no se hizo en la Sprint Review, tocará hacerlo en la primera parte de la Sprint Planning. 

En esta primera parte, es muy habitual también repasar las tareas que se han quedado a medias. Es normal repasar una a una para entender el trabajo restante. Si usáis estimaciones, es buen momento para reestimarlas (algo que no se recomienda a mitad de Sprint). 

El siguiente paso es conocer nuestra capacidad, ¿vamos a estar todos disponibles este Sprint? Podemos hablar de vacaciones, permisos u otros hechos. Además, si en este Sprint va a participar alguien con una dedicación baja, es un buen momento para que se comente cómo va a ser su participación. Con toda esta información, que podemos volcar en una Mural para visualizarlos juntos, toca trabajar. 

Ahora definimos nuestro Sprint Goal. ¿Para qué haremos este Sprint? ¿Cómo nos aportará valor? ¿Cómo nos acerca este Sprint el Product Goal que nos hemos fijado? Generalmente, esto lo responde el Product Owner y, entre todos, definimos nuestro Sprint Goal viable. 

Una vez hecho esto, pasamos a seleccionar los Product Backlog Items (PBIs) que realizaremos. Para esta parte, muchos equipos invierten mucho tiempo estimando. La estimación no es mala, pero es demasiado costosa en términos de tiempo. Aún así, mi consejo es que cojamos cada PBI y lo degranemos en tareas, y que nos centremos en los más raros o menos habituales. 

Si lo estudiamos, estamos dividiendo en tareas técnicas el trabajo funcional. Podemos también visualizar dependencias que sean clave tener en cuenta. Con este ejercicio podemos determinar lo que vamos a hacer. Recomiendo utilizar datos históricos por encima de puntos de historia. Si en los últimos Sprints nunca hemos pasado de nueve Items, pues usemos ese número. ¿Tiene sentido estimar más?

Cuando tengamos claro los items, podemos replantear el Sprint Goal. Quizás no sea viable, o sea muy ambicioso. Esto puede pasar en cualquier momento a medida que avance la Sprint Planning. Aunque, en mi experiencia, prefiero tener el Sprint Goal definido previamente que una vez seleccionado los items, porque muchas veces la definición es “hacer XYZ”. 

La siguiente parte es la más crítica, y donde más equipos cometen errores. ¿Cómo nos vamos a organizar para conseguir lo que hemos dicho que vamos a conseguir? Por ejemplo, podremos adelantar un trabajo para que una compañera lo haga ya que se va de vacaciones, aunque no sea prioritario para el Product Owner. Esta es la parte de la conversación más clave y donde un equipo autogestionado debe de dar un paso al frente. 

Hay muchos modos de organizarnos, pero la clave es la conversación. Por ejemplo, un modelo interesante es: ¿qué podremos esta semana? ¿y la que viene? De esta manera pensamos en lo que vamos a entregar y cómo averiguaremos a mitad de Sprint si hemos ido bien o mal. 

Una práctica interesante puede ser hacer un pre-reparto de tareas. De manera que visualicemos quiénes van a estar con ciertas tareas. Muchas veces, un determinado item requiere de varias personas trabajando juntas, por lo que saber con quiénes lo completamos es clave. 

También es recomendable que visualicemos el Definition of Done, y que no lo dejemos correr. Un consejo es que la Definition of Done se transforme en tareas concretas que podamos repartir y visualizar su estado en todo momento. 

Conclusiones

Durante la Sprint Planning, y más en digital, debemos tener claro que la autogestión es clave para que sea útil. Para que fluya, necesitamos disponer herramientas visuales que nos permitan avanzar. Tener esa conversación sobre cómo organizarnos es clave para que tengamos un espíritu de equipos y seamos capaces de entregar valor. 

Y tú, ¿cómo haces la Sprint Planning en remoto?