El Sprint Planning es el evento que arranca el Sprint en Scrum, durante este evento el Scrum Team en su conjunto colaboran para crear un plan que será el resultado de este evento y que permitirá alcanzar el objetivo del Sprint o Sprint Goal
Es importante saber que el principal propósito del Sprint Planning es alinear a los Developers con el Product Owner sobre qué construir a continuación, entregando el mayor valor posible a los clientes.
Indice de contenidos
Elementos necesarios en un Sprint Planning
En todos los eventos de Sprint Planning se requiere de unos elementos necesarios como entrada o input que sin ellos sería complicado o imposible realizar este evento. Y al final del evento debemos de asegurarnos de conseguir uno elementos como salida o output:
Entrada de un Sprint Planning en Scrum
- Product Backlog, que debería de estar ordenado y algo refinado
- El rendimiento del equipo, algunos suelen tener puntos de historia, otros tallas, otros número de PBIs o items. La idea es tener una referencia. A tener en cuenta que al principio el equipo no tiene esa info, pero, Sprint a Sprint la irá cogiendo.
- Acciones de mejora de la retro, Scrum es un marco de trabajo empírico y en su ADN está la mejora continua. ¿Qué acciones de mejora has identificado en tu retro y quieres introducir en este Sprint?
- Disponibilidad del equipo, no es lo mismo que esté una persona disponible que las 9 personas del equipo.
- Definition Of Done, si no sabemos lo que significa que un elemento del backlog está terminado o que cosas hay que hacer será muy complicado hacer una previsión.
Salida de un Sprint Planning
- Sprint Goal, que determina el Para Qué, que veremos más adelante
- Previsión del Sprint, el número de elementos del Backlog para poder alcanzar el objetivo
- El Sprint Backlog, es el conjunto del objetivo del Sprint, los PBIs seleccionados para el Sprint, más el plan para entregarlos.
Cómo funciona la Sprint Planning
Para entender bien cómo funciona un Sprint Planning debemos de entender su propósito y para tal fin, hay que hacerse las siguientes preguntas: ¿Para qué? ¿Qué? y ¿Cómo?
¿El para qué ?
Tenemos que pensar que cada Sprint es una inversión, por lo tanto es importante preguntarse, ¿Qué vamos a conseguir con está inversión? ¿Qué resultados tendremos? ¿Qué impacto conseguiremos?
Elaborando un buen Sprint Goal podríamos responder a todas estás preguntas.
¿El qué?
Una vez tenemos el Sprint Goal, que nos brindará dirección y sentido de para qué vamos a realizar una inversión de tiempo y dinero, debemos de comenzar a seleccionar los PBIs del Backlog que nos permitirán alcanzar este objetivo. Esto formará nuestra previsión, esta selección la hacen los developers o desarrolladores de producto.
¿El cómo?
Llegados a este punto, nos podemos plantear lo siguiente: ¿Cómo se va a hacer el trabajo? ¿Hay algo a diseñar? ¿Algo a investigar? ¿Se puede reutilizar algo de código? ¿Cómo mantenemos el nivel de calidad? etc. La idea es crear un plan para los 2 o 3 primeros días del Sprint y Daily a Daily el equipo puede ir haciendo pull de los elementos del Sprint Backlog, además que el Sprint Backlog podría cambiar conforme el equipo aprende y avanza.
Antipatrones de una Sprint Planning
En la mayoría de los eventos Scrum se suelen observar anti-patrones y la Sprint Planning no se libra. Vamos a ver algunos de estos antipatrones de la Planning en Scrum:
El PO o SM asigna las tareas a los Developers
A dia de hoy casi todos sabemos que el equipo hace pull de los PBIs que considera para alcanzar el Sprint Goal. Y el PO o SM no tiene que ir asignando tareas a las personas del equipo, si esto sucede, es una disfunción en el sistema y desde luego es un síntoma que el equipo no está siendo autogestionado :O. Además de esto, el los integrantes del propio equipo deben de evitar adueñarse cada uno de de las tareas.
Tareas basadas en Skills
Desde mi experiencia descomponer un PBI en: sub-tarea de FrontEnd (React), sub-tarea de BackEnd (Java), Diseño, etc. Solo genera separación e individualismo y rompe la responsabilidad compartida y muchas veces cada persona se dedica a lo suyo y se olvida de lo más importante => El Sprint Goal. He visto hasta FrontEnd o BackEnd cogiendo PBIs del Backlog ya que han terminado su parte y no pueden hacer más… Para ello muchas veces el equipo tiene que introducir conceptos como:
STOP STARTING AND START FINISHING
Esto fuerzo que se ponga foco en avanzar hacia el Sprint Goal y en muchos casos ayudarse el uno al otro y velar por los objetivos del equipo y no los individuales
Tener un Sprint Goal Vago
Recuerdo cuando le pregunté a un Product Owner: ¿Cuál será el objetivo del Sprint? y me respondió : estas 10 historias y 5 incidencias… mmm 🙁
Un objetivo genérico como este ejemplo no define el para qué del Sprint, no explica el motivo del para qué vamos a invertir tiempo, esfuerzo y dinero en este Sprint. Además de esto, si tenemos un objetivo claro del Sprint y que esté bien definido y con un Backlog bien ordenado, permite al equipo mantener el foco en el desarrollo de lo más importante y protegerles de la auto-organización.
Para conseguir un buen Sprint Goal piensa en lo siguiente: ¿Cómo se beneficiarán los usuarios del resultado de este Sprint?
Si quieres mas info puedes consultar esta pagina de ScrumDotOrg
Espero que te haya gustado este articulo, ayúdame a difundirlo y valóralo, me sería de gran ayuda. Y si necesitas ayuda no dudes en escribirme por correo o utilizando el chat
