Reunión de Sprint Planning

El inicio de cada Sprint es la Reunión de Sprint Planning. Se utiliza para definir la carga de trabajo del equipo Scrum para el próximo Sprint. Cómo debe prepararse la Reunión de Sprint Planning por el Product Owner, quién participa en ella, cómo es el proceso y a qué debe prestar atención el equipo, lo puedes leer en este artículo.

Sprint Planning: Objetivos y Participantes de la Reunión

Una reunión de Sprint Planning tiene dos objetivos. Después de un Sprint Planning exitoso:

• el product owner y el equipo de desarrollo acuerdan el objetivo del sprint (outcome)
• y han formado el Sprint Backlog. El Sprint Backlog contiene todos los Product Backlog Items que deben implementarse en el Sprint para lograr el Objetivo del Sprint (Output).

En algunos lugares, Outcome y Output también se resumen como MVP, el Producto Mínimo Viable.

¿Quién invita al Sprint Planning?

El Product Owner invita al equipo de desarrollo y al Scrum Master a la Sesión de Planificación Scrum. Si también hay Stakeholders que quieren ver cuál es el Objetivo del Sprint y en qué Backlog Items se está trabajando, el Product Owner también los invita.

Preparación de la Reunión de Planificación Scrum

Para que el product owner y el equipo de desarrollo logren los dos objetivos de la reunión de planificación, se deben cumplir algunos prerrequisitos. Por lo tanto, los siguientes pasos preparatorios son esenciales antes del Sprint Planning en Scrum. Si trabajas como PO tú mismo o te estás preparando actualmente para el rol de Product Owner, puedes usar esta lista de verificación o usar los ítems listados a continuación.

• El Product Owner ha definido un Objetivo del Sprint (Outcome) y ha seleccionado los Product Backlog Items (PBIs) asociados.
• Los PBIs seleccionados fueron formulados con suficiente detalle - preferiblemente en colaboración con el equipo de desarrollo, por ejemplo, como parte de un Product Backlog Refinement.
• Los PBIs seleccionados han sido puestos en un orden según el cual el equipo de desarrollo trabajará en ellos. Esto tiene en cuenta las dependencias técnicas.
• El equipo tiene una Definition of Done (DoD). Esto proporciona un entendimiento común de "cuándo algo está hecho".
• La capacidad del equipo para el próximo Sprint ha sido determinada, por ejemplo, teniendo en cuenta la velocidad promedio de los últimos Sprints y cualquier vacación planificada de miembros individuales del equipo.

El proceso de Sprint Planning

Una vez que el Sprint Planning está preparado como se describe, puedes comenzar con el proceso real con tu Equipo Scrum. La reunión procede según la siguiente Agenda de Sprint Planning:

• El Product Owner presenta el objetivo del sprint y los PBIs asociados y responde preguntas de comprensión del equipo. El Objetivo del Sprint debe ser documentado en el Sprint Backlog de una manera que sea fácil de leer para todos los miembros del equipo.
• Si los PBIs aún no han sido estimados, debes hacer la estimación ahora. Si la estimación ya ha tenido lugar, tu equipo ahora puede refinar la estimación después de la discusión detallada de implementación.
• El equipo hace una predicción al product owner y stakeholders sobre qué PBIs entregará al final del sprint según la DoD escrita colaborativamente. De esta manera, se forma el Sprint Backlog, en el que debe documentarse qué PBIs el equipo de desarrollo se ha comprometido y cuáles trabajará opcionalmente adicionalmente.

Por supuesto, en Scrum también hay un timebox para Sprint Planning: la duración de un Sprint Planning no debe ser más larga que un día (timebox: 8 horas).

Diferenciación en Sprint Planning 1 y 2

Nuestro consejo práctico: los equipos Scrum a menudo distinguen entre Sprint Planning 1 y 2:

• Sprint Planning 1 trata la pregunta: ¿qué queremos abordar en el próximo sprint?
• Sprint Planning 2 trata la pregunta: ¿Cómo queremos abordarlo?

Por cierto, el timebox de ambas planificaciones no se divide en 4 horas cada una - en su lugar, Planning 1 es automáticamente bastante corto después de un buen refinement, mientras que la mayor parte del timebox se necesita para Planning 2.

Aunque esto no es obligatorio, algunos equipos de desarrollo desglosan los Product Backlog items en paquetes de trabajo más pequeños (tasks) en Scrum Sprint Planning 2. Esta segunda parte del Sprint Planning a menudo tiene lugar sin el Product Owner.

¿Qué más debe considerar un equipo al planificar un sprint?

Un equipo de desarrollo nunca podrá trabajar exclusivamente en los ítems del sprint backlog seleccionados en un sprint, porque en cada entorno de trabajo ágil hay interrupciones, pequeñas emergencias y solicitudes de soporte urgentes en el medio.

Por esta razón, vale la pena que tu equipo planifique algún tipo de buffer en los sprints, que permite las siguientes actividades, por ejemplo:

• Solucionar problemas operativos, como cuando un servidor se cae.
• Solucionar bugs críticos
• Soporte técnico de primer o segundo nivel

Tales buffers aseguran que el Sprint Planning de Scrum produzca un backlog que el equipo realmente puede lograr sin frustrarse por fallos. Además, nuestros estudios muestran que los equipos con un buffer se vuelven más performantes con el tiempo. Esto se debe en parte al hecho de que estos equipos tienen más probabilidades de lograr sus objetivos de sprint, y por tanto tienen sentimientos de éxito más frecuentes.

Los resultados de la planificación del sprint

Si tú y tu equipo pueden marcar los siguientes ítems como hechos, sabes que tu planificación del sprint fue exitosa y hiciste todo bien:

• El equipo Scrum ha desarrollado un entendimiento compartido de lo que necesita lograrse en el próximo Sprint (Objetivo del Sprint).
• A través de la discusión del equipo de desarrollo entre sí, tienes un entendimiento común de cómo debe implementarse cada PBI.
• Has creado un Sprint Backlog claramente mapeado que contiene los PBIs en el orden del Product Backlog, posiblemente incluso después de un Task Breakdown incluyendo actividades asociadas.

El mayor error en la Reunión de Sprint Planning

Algunos equipos de desarrollo se atascan creando el Sprint Backlog perfecto tratando de identificar y estimar meticulosamente cada tarea, sin importar cuán pequeña sea. Por lo general, esto sucede cuando la gestión aún no ha penetrado completamente la forma de trabajar ágil y exige estimaciones tan "exactas".

Dado que se pierde demasiado tiempo en la reunión de Sprint Planning si la estimación es excesivamente precisa, el Scrum Master debe asegurarse de que el objetivo real de la planificación no se pierda: es decir, seleccionar los PBIs correctos para el próximo Sprint y hablar sobre ellos lo suficiente para que el equipo se sienta listo para trabajar en los ítems.

Resumen de la Reunión de Sprint Planning

Una Reunión de Sprint Planning exitosa se sostiene o cae en una buena preparación como el Product Backlog Refinement. La Reunión de Sprint Planning a su vez proporciona el prerrequisito de que todos en el equipo sepan qué se debe implementar en el próximo Sprint y cómo. Si el Sprint va a tener éxito y el equipo de desarrollo va a trabajar en los PBIs exitosamente y sin frustración, la Reunión de Planificación es absolutamente indispensable en Scrum.