¿Qué es el Sprint Planning?

El Sprint Planning (o planificación del Sprint) es uno de los cinco eventos de Scrum y es el primero que haremos al comenzar cada Sprint.
En esta reunión vamos a planificar QUÉ es lo que vamos a hacer durante el Sprint y CÓMO lo vamos a hacer.

¿Cuál es la duración del Sprint Planning?

El Sprint Planning tiene un timebox de hasta ocho horas para un Sprint de un mes. Si tenemos Sprints más acotados, la duración de esta ceremonia será adecuadamente más corta.

¿Cuál es el objetivo del Sprint Planning?

El objetivo es crear un Sprint Goal y un Sprint Backlog que incluye todos los elementos del Product Backlog requeridos para alcanzar el Sprint Goal acordado por todo el Equipo Scrum.

¿Cómo medimos el éxito de este evento?

Al finalizar este evento, los Developers (desarrolladores) deben ser capaz de exponer cómo piensan alcanzar el Objetivo del Sprint. Si lo pueden expresar con claridad, tendremos una buena señal de que han debatido con cierta profundidad todos los ítems seleccionados y lo comprenden. Esto amplía la probabilidad que tienen de cumplir con sus estimaciones.

¿Quiénes participan en el Sprint Planning?

Durante la planificación interviene todo el Equipo Scrum, es decir, el Product Owner, el Scrum Master y los Developers.
El Scrum Master se debe asegurar de que este evento ocurra y se cumpla su objetivo. También actuará como facilitador para evitar salirse del timebox asignado, o evitar que ciertas personas acaparen todas las conversaciones y decisiones.
El Product Owner se debe asegurar de que los asistentes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se relacionan con el Objetivo del Producto. Adicionalmente cualquier miembro del Equipo Scrum puede invitar a otros asistentes para brindar asesoramiento.

¿Cuáles son las 3 partes del Sprint Planning?

La estructura de la reunión está dividida de manera tal que aborde los siguientes temas: 

• Tema 1: ¿Por qué es valioso este Sprint?
• Tema 2: ¿Qué se puede hacer en este este Sprint?
• Tema 3: ¿Cómo se realizará el trabajo elegido?

Tema 1

El primer tópico: ¿Por qué es valioso este Sprint?

El Product Owner propone cómo el producto podría Incrementar su valor en el Sprint actual. Luego, todo el Equipo Scrum colabora para definir el Objetivo del Sprint que comunica por qué el Sprint es valioso para los stakeholders. El Objetivo del Sprint debe completarse antes de que termine la Sprint Planning.

Establecer el Sprint Goal

Luego de las conversaciones y el análisis que han hecho, el Equipo Scrum COMPLETO acuerda un Objetivo de Sprint. Este objetivo servirá como norte para los Developers, marcando el propósito de todo lo que estarán construyendo y estará visible durante todo el Sprint.

🏁 ¿Qué es exactamente el Sprint Goal?

El Sprint Goal (u Objetivo del Sprint) es una meta establecida para el Sprint por todo el Equipo Scrum que puede cumplirse a través de la implementación de PBIs (ítems del Product Backlog). Brinda una referencia para los Developers sobre el propósito de por qué crean el incremento que crean. También ayuda a aumentar la unión del equipo y fomenta la colaboración de sus miembros a través de trabajar enfocados y no en propuestas o proyectos separados.

Ejemplos de Sprint Goals

Para bajar un poco a tierra, les comparto algunos posibles ejemplos Sprint Goals:

• Reducir un 20% el tiempo de carga de la página del listado de “Productos con Descuentos”
• Modificar la forma en que los usuarios se registren para subir la tasa de conversión por lo menos en un 25%.
• Proveer un mecanismo para que los usuarios puedan dejar su feedback en cada producto.

Tema 2

El segundo tópico: ¿Qué se puede hacer en este este Sprint?

Una vez que se ha establecido el Objetivo de Sprint, los Developers analizarán el Product Backlog, la performance o velocidad de sus últimos Sprints y la capacidad proyectada para este Sprint. En base a ello, seleccionarán la cantidad de ítems del Product Backlog que consideren factible de completar.

Tema 3

El tercer tópico: ¿Cómo se realizará el trabajo elegido?

Una vez que se ha establecido el objetivo y seleccionado los PBIs para el Sprint, los Developers se reúnen para decidir y planificar cómo construirán cada elemento del Product Backlog para llegar a un Incremento de Producto que cumpla con la Definición de Terminado terminado.

El secreto para salir adelante es comenzar. El secreto para comenzar es dividir tus complejas tareas abrumadoras en pequeñas tareas manejables, y luego empezar con la primera.

Mark Twain

Dividir en tareas

Generalmente los Developers toman los PBIs seleccionados y los empieza a descomponer en partes más pequeñas a las que llamaremos tareas. Las tareas son todas las actividades que tienen que completarse para que un PBI cumpla con el Definition of Done (DoD). Al dividir los ítems en tareas se recomienda considerar que una tarea debe poder completarse en un día de trabajo.

La forma de descomponer o dividir los PBIs queda a criterio exclusivo de los Developers. Nadie más les dice cómo convertir los elementos del Product Backlog en Incrementos de valor.

Si al momento de dividir los PBIs en tareas, los Developers encuentra que no es posible terminarlos durante el Sprint, pueden llamar al Product Owner para re-negociar el alcance.

De la misma manera, si lo consideran necesario, pueden llamar a consultores técnicos o personas con mucho conocimiento en un dominio específico para que los ayuden a clarificar ciertos temas y poder establecer un mejor plan.

Cabe destacar que durante esta etapa no es necesario tener planificado hasta el último detalle, ya que durante el Sprint probablemente el contexto haga que las cosas vayan cambiando y será tiempo desperdiciado. Lo que buscamos más bien es tener listo el plan para los primeros días del Sprint y tener una noción de si vamos a llegar a completarlo.

El objetivo del Sprint, más el conjunto de PBIs seleccionados para el Sprint más el plan para completarlos denomina Sprint Backlog.

Objetivo de Sprint + PBIs seleccionados + Plan de ejecución = Sprint Backlog.

RESUMEN GRÁFICO del SPRINT PLANNING:

Patrones y buenas prácticas

La importancia de un buen Sprint Goal

El equipo se compromete a una corta declaración donde se describe el VALOR que pretenden entregar en el Sprint y esto se convierte en el foco de todo el trabajo.

El objetivo de un Sprint es entregar VALOR a los stakeholders, pero es necesario aclarar que seguir una lista de elementos del Sprint Backlog (como por ejemplo las tareas que dividieron) no necesariamente da como resultado la creación del MAYOR VALOR POSIBLE.

Cuando el equipo divide los PBIs en tareas pequeñas e individuales puede volverse sencillo comenzar a trabajar en ellas de manera aislada durante el Sprint. Esto disminuye la innovación que deriva de las distintas perspectivas que pueden aportar los miembros del Equipo ante un tema y sus interacciones. El trabajo en equipo cae.

Si bien utilizamos el Objetivo del Sprint para encuadrar los PBIs que seleccionamos, el Objetivo del Sprint es más importante incluso que la suma de los PBIs individuales. El Sprint Goal crea una conexión entre los PBIs, ayudando a crear un Incremento de Producto de gran valor.

Técnicas para armar los Sprint Goals

Una manera de llegar a conseguirlo puede ser aplicar la técnica de los cinco por qué. Esto se realiza a través de repetir la pregunta de “¿por qué seleccionamos estos PBIs para este Sprint?” hasta encontrar un hilo conductor entre todos los PBIs en lugar de tener un objetivo que sea solamente: “terminar todos los PBIs seleccionados.

Otra orientación es construir nuestro Product Backlog como una lista de Objetivos de Sprint, y luego todo el Equipo junto trabaja regularmente en la fabricación de PBIs partiendo de dichos objetivos. De esta manera, al llegar a una Sprint Planning, es muy fácil identificar el Objetivo de Sprint asociado a cada PBI.

Buena visibilidad

El Objetivo del Sprint debe ser transparente para todos. Para colaborar con esto es recomendable que éste se encuentre en un lugar bien visible y que funcione como un radiador de información.

Al tenerlo bien visible los Developers puede recordarlo fácilmente en todas sus Daily Scrum de manera que puedan sincronizarse teniendo en cuenta el objetivo principal para el cual se están sincronizando.

Hacer el refinamiento

El refinamiento, también conocido como PRE PLANNING o Product Backlog Refinement, ayuda a llegar al Sprint Planning con todos los elementos del Product Backlog en buenas condiciones.

Tener estos elementos listos significa, por ejemplo, que tengan toda la información necesaria para ser estimados, que no esten bloqueados por otros elementos y que no tengan dependencias externas.

Realizar el refinamiento mejora considerablemente la eficiencia del Sprint Planning y reduce en gran medida el tiempo de la reunión.

Prepararse para las interrupciones en el Sprint Planning

Prepararse para las interrupciones ayuda a los equipos a enfrentar circunstancias imprevistas y les da la oportunidad de cambiar su plan de trabajo todos los días durante la Daily Scrum sin perder horas de re-planificación.
Un estudio de la Universidad Carnegie Mellon demuestra que:

• Los equipos que se preparan de antemano para las interrupciones, las enfrentan un 14 por ciento mejor que los equipos que no lo hacen.
• Los equipos que se preparan para las interrupciones completan una tarea de interrupción en un 43 por ciento más rápido que los que no se preparan.

Es parte de construir la cultura del equipo, el prepararse para cosas no planificadas. De esta manera ante imprevistos, los equipos pueden cambiar hacia nuevas formas de proceder para poder avanzar sin ayuda externa.

Promover trabajar en una cosa a la vez

Uno de los creadores de Scrum añade que además de promover el foco, el Sprint Goal impulsa el trabajo “Swarming” (o trabajo en enjambre): ¿Podemos hacer que todos trabajen juntos en una cosa?
Él relata:

En Silicon Valley en 2007, Palm estaba trabajando en un sistema operativo web que luego fue adquirido por Hewlett-Packard. Sprint a Sprint los equipos estaban bien hasta que en un momento parecía que golpearon una pared luego de un par de Sprints. Los PBI no se estaban terminando. Los developers se desmotivaron y se fueron a casa temprano. Me trajeron y conseguí que los Product Owners y Scrum Masters pasaran una hora entrevistando a los miembros del equipo sobre por qué estaban desmotivados. Descubrimos que no entendían la razón por la que estaban trabajando tan duro en los PBIs de bajo nivel (tareas).

Pasamos una tarde limpiando el Product Backlog para muestre un vínculo claro entre las Historias de alto nivel y la jerarquía de descomposición. Tan pronto como los developers entendieron que el Objetivo del Sprint era mejorar el rendimiento del sistema operativo web en un 10%, se sintieron motivados para completar las historias de bajo nivel y la velocidad volvió a la normalidad.

Comprender por qué se implementan los PBI es fundamental para los developers, especialmente para los developers expertos que preferirían ir a surfear si no ven la razón de su trabajo.

Jeff Sutherland

Tener un segundo objetivo

Usualmente el Sprint Goal tiene que ver con VALOR en cuanto al producto. El equipo puede establecer opcionalmente objetivos de Sprint en términos de objetivos de procesos. Por ejemplo, hacer pair programming o ser puntuales con el horario de la Daily Scrum todos los días.

El Sprint Planning ES ÁGIL

Como hemos mencionado, el Sprint Planning produce la versión inicial del Sprint Backlog. Esto quiere decir que utilizamos este evento para que los Developers pueda comenzar a trabajar con cierta claridad y fluidez, pero para nada busca establecer un plan fijo e inamovible.

Recordemos que Scrum está diseñado para trabajar en contextos cambiantes, por lo que este plan se irá ajustando todos los días en el Daily Scrum.
El Daily Scrum es esencialmente un evento de re-planificación.

Hacé la Planning, pero tirá los planes.

Mary Poppendieck, conferencista y escritora del premiado libro Lean Software Development: An Agile Toolkit

Conclusiones

El Sprint Planning es un evento muy importante en donde todo el equipo Scrum trabaja para establecer un Objetivo de Sprint y un plan de trabajo. Tener un Objetivo de Sprint claro y un plan de trabajo organizado  promueven los valores de Scrum de foco y compromiso.