Planificación del Sprint y la capacidad del equipo.

La Planificación del Sprint (Sprint Planning meeting) basado en la capacidad del equipo debería de involucrar, al menos, a todo el Scrum Team (PO, SM, DT). El Product Owner hace visible los ítems requeridos y los ordena en el Product Backlog comenzando con los de mayor prioridad.

Seguidamente, las personas del Development Team, seleccionan el/los primer ítem/s para llevar al sprint. Generalmente será el ítem de máxima prioridad pautado por el Product Owner.

Los miembros del equipo de desarrollo debaten sobre el trabajo a realizar e identifican y descomponen las tareas necesarias y dependencias (en caso de que existan). Las estimaciones resultantes de este primer análisis muy probablemente sean aproximadas (dentro de un rango de tolerancia conocido) y se debe tener la certeza que al menos entrarán en un Sprint, caso contrario habrá que volver a descomponer con mayor granularidad.

Una vez alcanzado el acuerdo inicial, el equipo (con la votación y aprobación de todos los miembros) debería de preguntarse si con su capacidad actual puede comprometerse a realizar esas tareas durante el Sprint y entregar el incremento.

El compromiso grupal tiene mas fuerza que el individual, ya que el caso de que alguna persona tenga un impedimento o se retrase por algún motivo, cualquier persona del equipo irá en su ayuda para desatascar el problema y continuar avanzando. Por esa razón es de vital importancia la absoluta transparencia para comunicar el impedimento (en el mismo instante que surge o en todo caso en la Daily).

Cuando el Dev. Team ha completado el Backlog con los ítems seleccionados para el Sprint, el Scrum Master podría sumar los puntos de historia asignados y compartir y analizar el resultado con el equipo. Esto le permitirá al equipo tener una métrica muy valiosa para entender su capacidad con respecto a otros Sprints y visualizar los reisgos subyacentes y el posible riesgo de la deuda técnica.

Puede suceder que durante el Sprint el Dev. Team identifique nuevas tareas emergentes que no han sido reveladas durante la planificación del sprint o también pueden descubrir que la User Story es realmente más difícil de lo que creían inicialmente.

En estos casos, hay que informar inmediatamente al Product Owner y volver a estimar para ver si todavía es posible cumplir con el Sprint Goal y poder entregar el incremento acordado al finalizar el Sprint.

Es muy importante para el equipo definir el Sprint Goal

El Sprint Goal es un conjunto de objetivos para el Sprint que se puede cumplir mediante la implementación del Product Backlog. Son el resultado de la negociación entre el Product Owner y el Development Team.

Los objetivos de Sprint deben ser específicos y medibles. Si bien el trabajo seleccionado para el Sprint Backlog puede visualizarse como un pronóstico/estimación (que se ha calculado inicialmente), el Equipo de Desarrollo a lo que se compromete realmente, es a lograr el Objetivo del Sprint.

-------------------------------------------------------

Referencias: www.scrum.org/resources

www.scrumguides.org