Definición de Sprint Planning en Scrum

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, el Equipo de Desarrollo debe 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 el Equipo de Desarrollo.
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.

¿Cuáles son las 2 etapas del Sprint Planning?

La estructura de la reunión está dividida de manera tal que conteste los siguientes dos interrogantes:

  • ¿QUÉ podemos entregar para lograr un nuevo Incremento de Producto durante este Sprint?
  • ¿CÓMO lo vamos a conseguir?

Sprint Planning 1

El primer asunto: ¿QUÉ PODEMOS HACER en esta iteración?

Para responder a ello, todo el Equipo Scrum analizará el Product Backlog, la performance o velocidad del Equipo de Desarrollo de los últimos Sprints y la capacidad proyectada para este Sprint.
La cantidad de ítems del Product Backlog a tomar depende solamente del Equipo de Desarrollo.

Durante esta reunión el Product Owner debate con todo el equipo cuál es el Objetivo del Sprint a alcanzar. Explica y se asegura de su correcto entendimiento, de todos los detalles de los ítems del Product Backlog que deberían completarse para cumplir dicho objetivo.

Establecer el Sprint Goal

Luego de esta conversación y el análisis que han hecho, el Equipo Scrum COMPLETO acuerda un Objetivo de Sprint. Este objetivo servirá como norte para el Equipo de Desarrollo, 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 el Equipo de Desarrollo 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.

Sprint Planning 2

El segundo asunto: ¿CÓMO LO VAMOS A CONSEGUIR?
Una vez que se ha establecido el objetivo y seleccionado los PBIs para el Sprint, el Equipo de Desarrollo se reúne para decidir y planificar cómo construirán estas funcionalidades para llegar a un Incremento de Producto terminado durante el Sprint.

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

Para construir este plan, el Equipo de Desarrollo toma 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 técnicas 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.

Si al momento de dividir los PBIs en tareas, el Equipo de Desarrollo 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.

Al conjunto de PBIs seleccionados para el Sprint y todas las tareas que los componen se lo denomina Sprint Backlog.

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.

RESUMEN GRÁFICO del SPRINT PLANNING:

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 el Equipo de Desarrollo 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

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 desarrolladores 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 desarrolladores 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 desarrolladores, especialmente para los desarrolladores 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 el Equipo de Desarrollo 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