Sprint Planning orientado a la Velocity

Existen dos enfoques básicos para planificar un Sprint:

1. Sprint Planning orientado a la Velocity (considerando la carga de trabajo promedio de un equipo), y

2. Sprint Planning orientado al compromiso (considerando lo que un equipo cree que puede lograr en un Sprint).

Sprint Planning orientado a la Velocity

Aquí se trata del Sprint Planning orientado a la Velocity. La cantidad de trabajo planificada para el próximo Sprint debería corresponder aproximadamente a la de los Sprints anteriores. Esto presupone, por supuesto, que el tamaño del equipo se mantiene aproximadamente igual, que en los Sprints se realizan tareas similares, que los Sprints tienen aproximadamente la misma duración, etc. Las desviaciones de estas condiciones pueden detectarse fácilmente. Si, por ejemplo, un Sprint dura solo nueve días en lugar de diez debido a un día festivo, el equipo lo sabe de antemano.

Los pasos individuales del Sprint Planning orientado a la Velocity:

• Determinar cuál fue la Velocity promedio del equipo en Sprints anteriores.

• Seleccionar la cantidad correspondiente de Product Backlog Items en función de esta Velocity.

• Identificar las tareas individuales de las User Stories y considerar si podría ser la cantidad adecuada de trabajo.

• Evaluar si estas tareas requieren tanto trabajo como las de Sprints anteriores.

Veamos estos pasos con más detalle.

Paso 1: Determinar la Velocity promedio de un equipo

El primer paso en el Sprint Planning orientado a la Velocity es determinar la Velocity promedio del equipo. Algunos equipos ágiles se guían solo por la Velocity de su último Sprint. Muchos equipos creen que ese es el mejor indicador de lo que se puede lograr en el siguiente Sprint. Eso no es incorrecto. Sin embargo, puede ser útil mirar un poco más atrás (si esos datos están disponibles).

Para ello, se observa la Velocity de los últimos tres a ocho Sprints. Según la experiencia, esto permite predecir bastante bien los Sprints futuros. Por supuesto, no hay que exagerar y calcular el promedio de los últimos diez años. Eso no diría nada sobre la Velocity actual del equipo. Sin embargo, si los datos de Sprints anteriores están disponibles, no conviene mirar solo el último Sprint.

Paso 2: Seleccionar Product Backlog Items

En función de la Velocity promedio recién determinada, los miembros del equipo pueden seleccionar los items para el siguiente Sprint. En conjunto, estos deberían corresponder, al menos aproximadamente, a la Velocity promedio.
En este punto, el Sprint Planning orientado a la Velocity está en principio completado y puede realizarse en cuestión de segundos: una vez que el equipo ha seleccionado los Product Backlog Items según su Velocity promedio, está listo.

Paso 3: Identificar tareas (opcional)

A menudo, este breve tiempo para un Sprint Planning no es suficiente. Por ello, los equipos pueden añadir un tercer paso a su planificación, en el que se identifican las tareas a realizar.
Para ello, los miembros del equipo discuten cada Product Backlog Item seleccionado para el Sprint. Intentan determinar qué pasos de trabajo son necesarios para completar los items. Por supuesto, no se puede pensar en todo, pero se debe intentar incluir tanto como sea posible.

Después, el equipo considera si los items seleccionados y las tareas correspondientes llenarán el Sprint. En consecuencia, se pueden añadir o eliminar algunos items del Sprint.

Algunos equipos terminan su Sprint Planning en este punto, otros realizan un último paso:

Paso 4: Estimar las tareas (opcional)

Algunos equipos finalmente estimarán cuántas horas necesitarán para las tareas seleccionadas. Esto les permite reconocer si han planificado la cantidad correcta de trabajo.

Este texto proviene del blog de Mike Cohn y fue traducido al español.