Siguiendo la Guía Oficial de Scrum, La Sprint Planning es el primer evento o reunión que ocurre dentro del Sprint, y con ella se decide el trabajo que se llevará a cabo durante este ciclo. En la Sprint Planning participan todos los integrantes del Equipo Scrum (Scrum Master, Scrum Product Owner y Developers).
Al finalizar la Sprint Planning, el equipo debería contar con dos nuevos elementos:
→ Un objetivo para el nuevo Sprint.
→ Una lista de características del producto o servicio esperadas a partir del sprint y las tareas relacionadas a ellas (Sprint Backlog).
Antes de la Sprint Planning
Para aumentar el éxito de la planificación del Sprint es recomendable anticiparse en dos cuestiones fundamentales: los ítems del [Product Backlog](/es/self-learning/scrum/conoce-el-product-backlog (aquí es donde el Product Owner juega un papel central) y quiénes serán los participantes de la Planning Meeting (adicionalmente al Equipo Scrum).
Es recomendable llegar a la Planning meeting con un Backlog del Producto que cumpla con las características DEEP (Pichler, 2010):
→ Detallado de manera apropiada: un product backlog debe tener un nivel de detalle apropiado en los ítems de mayor prioridad e ir reduciendo su nivel de detalle en la medida que la prioridad de los ítems va bajando. En una reunión de planificación de Sprint, interesan especialmente los ítems de mayor prioridad. Es importante asegurar que estén bien detallados para que los integrantes del equipo se sientan seguros de asumir el compromiso para el Sprint.
→ Estimado: parte de la reunión de Planificación del Sprint incluye la estimación de los ítems. Los equipos logran mejores resultados cuando los ítems del Product Backlog han sido estimados previamente a esta reunión. Esta estimación puede hacerse durante el Sprint o en una reunión dedicada al refinamiento del Product Backlog. Luego se confirma la estimación durante la reunión de planificación.
→ Emergente: el Product Backlog no es un elemento estático: está vivo, es orgánico, crece. Esta variabilidad está dada por el feedback y el aprendizaje que los stakeholders y el equipo van adquiriendo a través del tiempo. Antes de planificar el nuevo sprint, es clave trabajar con el Product Owner para garantizar que todo el feedback y aprendizaje del Sprint anterior estén incluidos en el Product Backlog.
→ Priorizado: un Product Backlog saludable representa la estrategia de creación del producto o servicio a través de la priorización de sus ítems. Previo a una Sprint Planning, es importante que el Product Owner tenga identificada la prioridad de cada ítem. Una buena referencia es que el Product Owner llegue a la reunión de planificación con una cantidad de ítems tal que el esfuerzo estimado sume el equivalente a dos Sprints (Cohn, Sprint Planning Meeting).
Objetivo del Sprint
Una de las primeras actividades recomendadas es establecer el objetivo para el nuevo Sprint.
El Sprint debería tener un objetivo compartido de forma tal que asegure que todo el equipo se mueva en una misma dirección. Una vez establecido dicho objetivo, los miembros del equipo son los responsables de alcanzarlo (Pichler, 2010).
Tener un objetivo claro para el Sprint es fundamental para facilitar las decisiones que el Equipo Scrum tome de manera autónoma durante la ejecución, entre ellas: cambiar alguna prioridad, redefinir alguna característica, negociar un recorte de alcance e, inclusive, proponer la cancelación de un Sprint. Todas estas decisiones responderán mejor al problema surgido si se toman con pleno conocimiento del objetivo del Sprint.
Tanto los stakeholders como el Product Owner pueden relacionar el Objetivo del Sprint con el Objetivo de Producto, y a su vez, con algún objetivo del negocio. De esta manera, el trabajo comienza a mostrar cierta coherencia explícita.
¿Qué vamos a hacer?
Una vez establecido el objetivo del Sprint es hora de determinar el incremento de producto que se entregará al finalizar el ciclo. A esta instancia ya debería haber llegado el Product Backlog priorizado y con los ítems candidatos para este Sprint detallados para que el Equipo pueda tomar sus compromisos.
Un elemento que funciona muy bien para contextualizar y mantener las conversaciones enfocadas, es un panel de actividades con tres columnas. La primera columna corresponde a los pendientes y allí se listan los ítems del Product Backlog. Al tratar un ítem se lo traslada a la segunda columna denominada ‘en progreso’ y, una vez finalizado, se coloca en la tercera columna de terminados. Esto se realiza de a un ítem por vez, mientras el equipo va asumiendo los compromisos respectivos para el Sprint.
Esta actividad finaliza cuando el Equipo determina que ya no puede comprometerse a asumir más trabajo para el nuevo Sprint.
¿Cómo lo vamos a hacer?
Una vez identificados todos los ítems comprometidos para el Sprint, es momento de identificar las tareas que el Equipo debe realizar para entregar el incremento del producto y, eventualmente, un diseño técnico o acuerdo marco de trabajo. En esta parte de la reunión, lo usual es que se quede trabajando sólo el Equipo, principalmente los Desarrolladores, mientras que los stakeholders se retiran.
Si el Product Owner participara en esta parte de la reunión, habrá que estar atento para que no ejerza influencia en la manera de hacer las cosas, lo cual es una potestad exclusiva del resto del Equipo Scrum.
Diseño marco
Durante la búsqueda de tareas y la planificación del Sprint surge la necesidad de diseñar lo que se hará. Lo importante en este punto es que el diseño se centre, exclusivamente, en lo que atañe al nuevo Sprint y no se extienda más allá de lo que se ha comprometido. Todo diseño en este momento es un acuerdo y no un compromiso rígido. Si el resultado de esta conversación de diseño necesita cambios durante la ejecución del Sprint, es importante que se visibilicen al resto del equipo.
Ítems listos y Definition of Ready
Una práctica usual para optimizar el uso del tiempo durante la reunión de Planificación del Sprint, es llevar los ítems del product backlog lo suficientemente listos, para que los miembros del equipo puedan asumir el compromiso de realizarlos en ese sprint. Lo que significa “suficientemente listo” es un acuerdo a generar dentro del equipo y se conoce habitualmente como Definición de Listo (Definition of Ready).
Al respecto, Jeff Sutherland recomienda el siguiente modelo para definir un ítem del Product Backlog (Sutherland, Definition Of Ready, 2014):
Debe estar definido con suficiente claridad de forma tal que todos los miembros del equipo entiendan lo que debe hacerse.
Incluye una definición clara del valor que aporta al negocio, de forma tal que el Product Owner puede entender su prioridad.
Incluye cualquier otra característica que ayude a su claridad: especificaciones, wire-frames, etc.
Satisface plenamente los criterios de INVEST.
Está libre de dependencias externas.
Participantes de la Planning meeting
Por definición, en una reunión de este tipo participa todo el Equipo Scrum Schwaber & Sutherland, Scrum Guide
Stakeholders
Los mejores resultados suelen suceder cuando participan los stakeholders o partes interesadas claves, aquellos vinculados a los ítems del Product Backlog que podrían ser comprometidos en el nuevo Sprint.
Part-timers
Uno de los pilares fundamentales de la Agilidad es el foco. El trabajo enfocado de las personas contribuye significativamente a la calidad y la creatividad. Por eso, se recomienda trabajar en un solo proyecto por vez. Ahora bien, muchas veces se tarda un tiempo considerable en lograrlo y es parte de una evolución organizacional que involucra cuestiones estructurales y culturales. En muchas organizaciones, el trabajar en un solo proyecto tiende a ser un escenario utópico debido a la alta especialización de las personas.
Por estas razones, mientras se preserva el objetivo de fondo -que es bajar el nivel de especialización y lograr perfiles con cierto grado de multidisciplinariedad-, habrá que aprender a convivir con los perfiles part-time. Estos perfiles pueden ser diseñadores, expertos en usabilidad, arquitectos, especialistas en seguridad, etc. Todos comparten una característica básica: brindan servicio a varios equipos en paralelo.
Si en tu equipo participan personas part-time, recuerda invitarlas a la Planificación del Sprint. Algo que suele suceder en este tipo de escenarios es dejar a estas personas fuera de las planificaciones y asumir compromisos en su nombre, lo cual no siempre genera buenos resultados.
Agenda
Una agenda visible por todos ayuda mucho a que la reunión fluya y evita desvíos, y ramificaciones innecesarias. Ante posibles dispersiones, sólo es necesario recordarle a los participantes el objetivo principal de esta reunión: planificar el Sprint.
Cronómetro
“El tiempo no nos alcanza.”
El tiempo es el tiempo, nadie tiene más o menos tiempo que otra persona. Por lo tanto, es imposible que el tiempo no alcance. La clave está en la manera en la que administramos nuestro tiempo. Y por lo general lo administramos bastante mal por falta de conciencia. Por ejemplo, no sabemos cuánto tiempo ha pasado ni cuánto queda. Por esta razón, contar con un cronómetro visible y establecer un time-box es clave en este tipo de reuniones, ya que ayuda a que los participantes auto-gestionen el tiempo.
Es probable que al principio sea necesario mostrar el cronómetro para recordar a los participantes la cantidad de tiempo disponible. A medida que el equipo desarrolle su experiencia en estas reuniones, el facilitador podrá irse apartando gradualmente para dejar que los participantes gestionen el tiempo por sí solos.
Parking-Lot
Es recomendable contar con un Parking-Lot para acciones emergentes. Muchas veces surgen dudas y necesidades de información o de verificaciones a realizar que, al no quedar registradas, corren el riesgo de perderse en el camino. Un Parking-Lot en el que se puedan colocar las notas con los accionables emergentes ayudará a no perderlos de vista. La recomendación es que cada accionable tenga un responsable claro.
Retrospectiva de planificación
Como siempre, al finalizar una reunión, es recomendable realizar una pequeña retrospectiva rápida que brinde información para mejorar la dinámica de la reunión, la agenda, la logística, etc.