Descubre cuales son los pasos para una buena planificación para tu equipo de trabajo
Cada Sprint comienza con una actividad acotada en el tiempo (timeboxed) llamada Planificación del Sprint. En esta reunión el Equipo Scrum colabora para seleccionar y comprender el trabajo que será realizado en el Sprint que está por comenzar.
¿Qué es un Sprint Planning?
Sprint Planning (Planificación de la Iteración)
Al inicio, cuando empezamos el proceso de construcción de un producto, el Product Owner parte por entender: ¿Cuál es la necesidad que impulsa la construcción del producto? ¿Cuáles son las necesidades que han provocado que nuestro cliente considere la necesidad de construir un producto que la supla? ¿Cuál es el beneficio esperado por el cliente sobre la construcción o desarrollo del producto? Estas preguntas le permiten definir la VISIÓN del producto, la meta que guiará la construcción del mismo.
Luego es importante que, en base a las expectativas del cliente y a lo que es más importante para su organización, el Product Owner defina los “hitos” de entrega (Release Planning) qué nos dirán, cuándo se darán las liberaciones del producto. Plantear estas liberaciones desde una perspectiva de objetivos, y no de características o funcionalidades, ayuda a enfocar mejor la construcción del producto. También se convierte en un apoyo para la toma de decisiones cuando hay que hacer un refinamiento del backlog y revisar el plan de liberaciones, debido al conocimiento ganado sobre el producto u otras cuestiones que pueden ir apareciendo por el camino. Por esta razón en este punto, planteamos la utilización de la Hoja de Ruta orientada a Objetivos (GO Product Road Map de Roman Pitchler) como forma de conseguir el plan de liberaciones a nivel Macro.
El tener una hoja de ruta orientada a objetivos, nos permitirá también generar desde otra perspectiva el Backlog del producto, pues los objetivos nos ayudarán a mantener el norte al definir las características que deberá tener el mismo.
Es bueno recalcar en este punto que el Product Owner debe siempre estar adelantado en historias de usuario detalladas por lo menos dos Sprints, de manera que esto le permita que el equipo asuma el compromiso del Sprint en función de su capacidad y del tamaño de las historias a construir/desarrollar.
A continuación veamos lo que la Scrum Alliance nos dice sobre los Sprint Plannings, el siguiente texto es tomado del documento “Core Scrum” en la versión traducida al español:
Planificación del Sprint
Cada Sprint comienza con una actividad acotada en el tiempo (timeboxed) llamada Planificación del Sprint. En esta reunión el Equipo Scrum colabora para seleccionar y comprender el trabajo que será realizado en el Sprint que está por comenzar.
El equipo completo participa de la reunión de Planificación del Sprint. Trabajando a partir del Product Backlog ordenado, el Product Owner y los Miembros del Equipo de Desarrollo discuten cada ítem y llegan a un acuerdo compartido respecto al mismo y al trabajo necesario para completarlo en forma consistente con la Definición de Hecho actual. Todas las reuniones de Scrum son acotadas en el tiempo. El tiempo recomendada para la Planificación del Sprint es de dos horas o menos por cada semana de duración del Sprint. Debido a que la reunión está acotada, el éxito de la Planificación del Sprint es altamente dependiente de la calidad del Product Backlog utilizado. Es por esto que el Refinamiento del Product Backlog es una actividad importante en Scrum.
En Scrum, la Planificación del Sprint se describe como compuesta de dos partes:
- Determinar qué trabajo será realizado en el Sprint.
- Determinar cómo realizará el trabajo.
Parte Uno: ¿Qué trabajo será realizado?
El Product Owner presenta en orden ítems del Product Backlog al Equipo de Desarrollo, y el Equipo Scrum completo colabora para comprender el trabajo a realizar. Para decidir cuántos ítems tomar, el Equipo de Desarrollo considera el estado actual del Incremento de Producto, la performance del equipo en el pasado, la capacidad actual del equipo y el Product Backlog ordenado. Ni el Product Owner, ni ninguna otra parte interesada, pueden solicitarle más trabajo al Equipo de Desarrollo del que pueden tomar.
A menudo, aunque no siempre, se le da un objetivo al Sprint, llamado Objetivo del Sprint. Ésta es una práctica muy poderosa que ayuda a todos a enfocarse en la esencia de lo que debe ser realizado, minimizando la importancia de detalles que pueden no ser importantes para lo que realmente queremos lograr.
Parte Dos: ¿Cómo será realizado el trabajo?
En la segunda parte de la reunión, el Equipo de Desarrollo colabora para decidir cómo producir el próximo Incremento de Producto de acuerdo con la Definición de Hecho actual. Sus miembros realizan el diseño y planificación mínimo suficiente como para poder confiar en que se podrá completar el trabajo durante el Sprint. El trabajo a realizarse los primeros días se divide en pequeñas unidades de un día o menos. El trabajo a realizarse más adelante puede dejarse en unidades más grandes, a ser descompuesto luego.
Decidir cómo hacer el trabajo es responsabilidad del Equipo de Desarrollo, así como decidir qué hay que hacer es responsabilidad del Product Owner, que puede quedarse en esta parte de la reunión para responder preguntas y resolver malentendidos. Sea cual fuere el modo, estas respuestas deberán estar fácilmente disponibles.
A menudo, aunque no siempre, se le da un objetivo al Sprint, llamado Objetivo del Sprint. Ésta es una práctica muy poderosa que ayuda a todos a enfocarse en la esencia de lo que debe ser realizado, minimizando la importancia de detalles que pueden no ser importantes para lo que realmente queremos lograr.
En la segunda parte de la reunión, el Equipo de Desarrollo colabora para decidir cómo producir el próximo Incremento de Producto de acuerdo con la Definición de Hecho actual. Sus miembros realizan el diseño y planificación mínimo suficiente como para poder confiar en que se podrá completar el trabajo durante el Sprint. El trabajo a realizarse los primeros días se divide en pequeñas unidades de un día o menos. El trabajo a realizarse más adelante puede dejarse en unidades más grandes, a ser descompuesto luego.
Decidir cómo hacer el trabajo es responsabilidad del Equipo de Desarrollo, así como decidir qué hay que hacer es responsabilidad del Product Owner, que puede quedarse en esta parte de la reunión para responder preguntas y resolver malentendidos. Sea cual fuere el modo, estas respuestas deberán estar fácilmente disponibles.
A menudo, aunque no siempre, se le da un objetivo al Sprint, llamado Objetivo del Sprint. Ésta es una práctica muy poderosa que ayuda a todos a enfocarse en la esencia de lo que debe ser realizado, minimizando la importancia de detalles que pueden no ser importantes para lo que realmente queremos lograr.
Resultado de la Planificación del Sprint
La Planificación del Sprint concluye cuando el Equipo Scrum llega a un acuerdo común respecto a la cantidad y complejidad de lo que se planea realizar durante el Sprint y dentro de un rango de circunstancias razonables espera poder completarlo. El Equipo de Desarrollo pronostica la cantidad de trabajo que completará y se compromete a realizarlo.
Sprint Backlog
El Sprint Backlog es la lista de ítems del Product Backlog refinados que han sido elegidos para ser desarrollados en el Sprint actual, junto al plan del equipo para poder realizar el trabajo. Refleja el pronóstico de qué trabajo puede ser completado.
Generado el Sprint Backlog, comienza el Sprint y el Equipo de Desarrollo estipula el nuevo Incremento de Producto definido por el Sprint Backlog.
Antipatrones de Sprint Plannings
No tener una Definición de DONE
El no tener una definición de DONE, dificulta al equipo el poder conocer cuando una tarea está adecuadamente concluida y puede propiciar el aumento no consciente de la deuda técnica al final del Sprint.
Es importante que los equipos, en conjunto con el Product Owner y en una reunión facilitada por el Scrum Master, definan los puntos que cada incremento del producto construido debe cumplir a fin de considerarlo como listo para ser entregado. Contar con esta definición en el Sprint Planning facilita a los equipos el dimensionar el esfuerzo necesario.
Generado el Sprint Backlog, comienza el Sprint y el Equipo de Desarrollo estipula el nuevo Incremento de Producto definido por el Sprint Backlog.
No tener Sprints de duración fija
Esto afecta directamente la predictibilidad del equipo sobre el trabajo a realizar y dificulta las estimaciones. Predecir cuánto tiempo nos demoramos en desarrollar/construir algo va de la mano de la “experiencia” (haberlo realizado, vivido, sentido, sufrido, etc.) y las referencias que tenemos sobre esta experiencia. Si continuamente cambiamos el “TIMEBOX” del Sprint (duración del Sprint) afectamos esa capacidad de predecir.
El Product Owner estima por nosotros
El hacer que quienes construyen las cosas sean quienes realicen las estimaciones se debe a que poseen el conocimiento de los detalles de cómo construir/desarrollar y por esto su estimación tiene muchas más posibilidades de ser más acertada. Además de que enriquecerán los tiempos de esa estimación con los detalles propios del proceso de construcción.
Asumir User Stories que no pudieron ser estimadas
Dentro de un Sprint, comprometerse a construir algo sobre lo que no se puede estimar presenta muchos riesgos de cara a poder entregar el incremento. En este caso, si la historia no puede ser estimada es aconsejable revisarla nuevamente, estudiar la posibilidad de dividirla o de realizar spikes. Para que las historias entren a un Sprint Planning es importante que cumplan con la definición de READY.
Aceptamos que el Sprint Backlog sea cambiado durante el sprint
Modificar el Sprint Backlog durante el Sprint afecta el compromiso de entrega del equipo. Estimar a fondo en lapsos cortos de tiempo (Sprints) tiene como fin asegurar el poder entregar el incremento al final de ese lapso. Modificar las tareas a realizar tira al suelo ese compromiso de entrega.
5 Mandamientos del Sprint Planning
- PO debe estar por lo menos un Sprint adelante del equipo
- No extender la duración del Sprint
- No incluir tiempo extra
- No agregar trabajo extra
- Entregar después de cada Sprint
