Hace tiempo creamos un test sobre la Daily Scrum y otro sobre la Sprint Review, ¡toca la Sprint Planning!
¿Tenemos claro en qué consiste la Sprint Planning? ¿Quiénes deben ir? ¿Cuanto tiempo nos debe llevar?
Os dejamos este test, tenéis que marcar todas aquellas frases que consideréis verdaderas. Después, explicaremos cada una de las frases: ¡Adelante!
¿Cuántas habéis marcado? Realmente, ninguna de las opciones es correcta, la mayoría son mitos sobre la Sprint Planning. Debemos tener muy claro qué es obligatorio y que es práctica recomendada a la hora de hacer la Sprint Planning. Si una práctica recomendada no nos está funcionando, pero insistimos en hacerla porque “lo dice Scrum”, podemos afectar a nuestra entrega de valor. El objetivo de este test es hacer reflexionar sobre cómo hacemos la Sprint Planning. Os explicamos las respuestas.
El Product Owner tiene que estar presente durante todo el evento
El Product Owner es una pieza clave en la Sprint Planning, y comparte su accountability con el resto del Scrum Team. Sin embargo, no tiene por qué estar todo el evento. En la primera parte, tendremos una conversación sobre qué se hará durante el Sprint. Después, el development Team debe reunirse para autoorganizarse y llevar a un plan (Sprint Backlog) de cómo se van a organizar para alcanzar lo que han previsto.
En esta segunda parte, no necesitamos que el Product Owner esté presente, no es obligatorio. Es más, Scrum aclara que, en esta parte, puede haber estimaciones, y que en ese caso, el Product Owner no debe influir en ellas.
De hecho, en la Sprint Planning, hay una “tercera parte” en la que el Development Team explica al Scrum Master y al Product Owner cómo se van a organizar, para alcanzar el Sprint Goal que se han marcado.
Es facilitada por el Scrum Master
Esta respuesta es interesante, realmente este evento puede ser facilitado por un Scrum Master. De hecho, cualquier evento de Scrum puede facilitarse por el Scrum Master si se lo piden o si entiende que se necesita (porque no está saliendo bien). Aún así, no es obligatorio que la Sprint Planning sea facilitada por el Scrum Master.
Hacemos esta pregunta porque hemos visto muchos equipos en los que el Scrum Master es quien dirige la sesión, controla el Jira, presiona para que se hagan estimaciones, no deja al equipo organizarse y sustituye al Product Owner en sus labores de explicarle al equipo lo que queremos conseguir en este Sprint.
Un Scrum Master suele enseñar a los equipos que no tienen experiencia en Scrum, pero debe dejar poco a poco que fluya la comunicación entre Product Owner y Development Team.
Se debe estimar todo lo que va a “entrar”
Lo importante es entender que en una Sprint Planning no se tiene por qué estimar o no estimar: ambas aproximaciones son correctas. Pero, muchas personas no saben que no tienes por qué llenar todo el Sprint. Hay casos en los que la incertidumbre nos impide saber cuánto vamos a poder entregar. En esos casos, podemos seleccionar algunos elementos para los primeros días y hacer más planificaciones a lo largo del Sprint.
A veces, es mejor empezar a trabajar para resolver algunas dudas en vez de teorizar en base a una incertidumbre.
Es obligatorio utilizar el Planning Poker
El planning póker es una herramienta muy extendida dentro de los equipos Scrum. Sin embargo, no es obligatorio utilizarla. A pesar de que es una técnica muy buena porque fomenta la conversación de las participantes y la reflexión personal. Pero a veces, se convierte en una herramienta muy dura que copa demasiado tiempo de la planning y evita e impide, por ejemplo, que tengamos conversaciones sobre cómo organizarnos. No debemos dar más importancia a la estimación que a la organización, generalmente esto ocurre cuando trabajamos con mentalidad tradicional.
Por tanto, el Planning Poker es de esas técnicas que podemos incluir en su equipo si lo necesitamos pero que no son obligatorias.
El resultado de la Sprint Planning es un tablero Kanban
Uno de los errores más comunes es pensar que el resultado de la Sprint Planning es un tablero Kanban. De la Sprint Planning obtenemos un Sprint backlog que puede estar en formato de tablero pero no tiene por qué.
El Sprint Backlog puede ser un tablero Kanban, pero en ese caso tiene que tener algunas características, como políticas explícitas de trabajo o limitación del WIP. Esto es importante, ya que muchos equipos llaman tablero Kanban a cualquier tablero visual, y son cosas muy diferentes. Se bBusca la gestión del flujo de trabajo y un tablero visual, simplemente, ayuda a un mejor entendimiento de lo que está ocurriendo. Kanban necesita de un tablero visual pero un tablero visual no tiene por qué ser Kanban.
El tablero debe contener como mínimo los estados: todo / doing / done
Hay muchas maneras de organizar tu tablero. El modelo todo-doing-done, desde nuestro punto de vista,mi opinión está pensado para equipos en los que todos sus miembros hacen cualquier tipo de tarea. Aunque he podido trabajar en equipos con miembros capaces de acometer casi cualquier tarea, no es lo habitual (ni obligatorio). Los estados todo-doing-done están muy extendidos entre muchos equipos Scrum, pero este no prescribe cómo organizarte.
Es mejor tener una conversación sobre cómo organizarnos que tratar de rellenar este tablero. Generalmente, esto ocurre por culpa de las herramientas digitales (como Jira) y pecamos de adaptarnos nosotros a la herramienta, en vez de que esta se adapte a nuestra situación.
De la Sprint Planning debemos salir con un compromiso de lo que vamos a entregar
En Scrum, fomentamos el valor “compromiso”, pero hay diferencias entre “estar comprometidos” y “tener un compromiso”. Hace muchos años que se eliminó la palabra compromiso de la Sprint Planning y se cambió por previsión (forecast).
En Scrum, asumimos que hay incertidumbre, y que pueden aparecer cambios durante el Sprint. Por eso, no podemos “comprometernos” a un entregable. Eso sí, debemos estar comprometidos con nuestro equipo, y con hacer las cosas bien.
Necesitamos conocer la velocidad del equipo antes de la Sprint Planning (salvo en la primera Sprint Planning)
En Scrum, no se habla de velocidad, se habla de “desempeño” (performance). Es cierto que la velocidad, entendida como puntos por Sprint, puede ayudarnos, pero recordemos que son métricas estimativas, siguen en el mismo paradigma de previsión (en Scrum buscamos la adaptación).
En nuestra opinión, es preferible usar métricas “a posteriori”. Por ejemplo, medir el número de PBIs por Sprint nos da una medida de la capacidad que el equipo tiene para desarrollar software y entregar valor. Por tanto, mucho cuidado con obsesionarnos con la velocidad, ya que no es un dato empírico y está basado en estimaciones, por tanto, es inventado.
Todas las historias de usuario que entran en la Sprint Planning deben de cumplir la Definition of Ready
El Definition of Ready hoy en día no está incluido en Scrum a pesar de que Jeff Sutherland lo incluye en su libro. Es una de esas técnicas que podemos añadir al equipo si consideramos que nos puede ayudar. Hay que tener cuidado porque, como toda técnica mal utilizada, puede generar un problema.
Lo importante es entender que la Definition of Ready nos ayuda a tener una conversación sobre cuánto debemos trabajar los elementos del Product Backlog (PBIs) y, así, lograr para tener una Sprint Planning más productiva. Sin embargo, no puede ser un freno para la Sprint Planning. Si un elemento no cumple la Definition of Ready, debería poder entrar en la Sprint Planning, y, si conseguimos que lo la cumpla, debería acometerse durante el Sprint. Obviamente, si traemos muchos elementos que no cumplan la DOR, la Sprint Planning se volverá muy larga y pesada
Conclusiones
Esperemos que os haya vaya parecido útil este pequeño cuestionario, ¿cuánto habéis sacado?
