Compartir

Cómo hacer un Sprint Planning

11/11/22 - 3 minutos de lectura

Un Sprint comienza con la reunión de Sprint Planning, en la que se planifica el trabajo a realizar en ese Sprint. En esta reunión, el Equipo de Desarrollo y el Product Owner negocian lo que se desarrollará, en función de los elementos de la parte superior del Product Backlog. Es decir, seleccionan un conjunto de elementos de la parte superior del Product Backlog , facilitados por el Scrum Master, que estiman poder desarrollar en la duración del Sprint, aunque es solo una previsión; y establecen un objetivo o meta de negocio para alcanzar con el desarrollo de estos elementos, denominado Objetivo de Sprint. Luego, el Equipo de Desarrollo se compromete a lograr este Objetivo de Sprint.

Organización de los elementos para el Sprint Planning

Es importante que los elementos de la parte superior del Product Backlog estén preparados para que la reunión de Sprint Planning sea eficiente y productiva. Los elementos que llegan a la reunión sin suficientes detalles, por ejemplo, pueden poner en riesgo todo el Sprint.

Cómo hacer un Sprint Planning 1

Ejemplo de la Definición de Hecho

Para asegurarse de que estos elementos estén listos para su discusión en la reunión de Sprint Planning, se puede crear y usar una Definición de Hecho. Estos son criterios claros que definen lo que se necesita para que un elemento esté listo para su desarrollo.

Si un Equipo Scrum elige usar una Definición de Hecho, el Equipo de Desarrollo tiene la prerrogativa de rechazar, en la reunión de Sprint Planning, un elemento que no esté preparado de acuerdo con esta definición.

Además del detalle necesario, por ejemplo, otros criterios en la Definición de Hecho pueden incluir que el elemento sea lo suficientemente pequeño y que tenga definidos los Criterios de Aceptación, entre otros.

En el primer Sprint, el Equipo de Desarrollo aún no tiene los datos para generar métricas sobre su capacidad para trabajar en un Sprint. Puede estimar los elementos del Product Backlog individualmente para que en un futuro sea posible obtener estas métricas útiles para la planificación.

Por cierto, Story Point es una unidad muy utilizada por los equipos Ágiles en su estimación. A partir de los siguientes Sprints, el Equipo de Desarrollo puede usar como parámetro la cantidad promedio de trabajo entregado en los últimos Sprints, que se puede medir en Story Points.

Cómo hacer un Sprint Planning 2
Ejemplo de Pizarra de Tareas (Sprint Backlog)

Otra forma de obtener estas métricas es dividir y hacer siempre muy pequeños los elementos de la parte superior del Product Backlog, con poca variación de tamaño entre ellos. Luego, contar la cantidad de elementos entregados en los últimos Sprints y calcular el promedio.

En cualquier caso, esta cantidad de trabajo que se espera realizar por Sprint se denomina Velocidad del Equipo de Desarrollo.

Además de seleccionar los elementos y definir una meta junto con el Product Owner, el Equipo de Desarrollo también crea un plan sobre cómo se desarrollará lo que se ha seleccionado. Este plan generalmente se expresa mediante tareas a realizar durante el Sprint.

El conjunto de elementos seleccionados y su respectivo plan se denomina Sprint Backlog y generalmente se representa en forma de Pizarra de Tareas.

Compartilhe

Escrito por

K21

Evolução Contínua de Pessoas e Organizações


Transformar pessoas e organizações ao redor do mundo é o que nos move. Mais do que ferramentas e métodos, promovemos uma nova cultura, onde negócios e pessoas entregam valor continuamente, experimentando, aprendendo e melhorando diariamente.
Esta publicación tiene la licencia Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artículos relacionados

Product Backlog: Épico, Historia de Usuario y Tareas
26/05/20
4 minutos de leitura
Product Backlog, planificación continua y la analogía del horizonte
12/10/18
2 minutos de leitura

    ¿Quieres recibir nuestro contenido?

    Escribe tu nombre y correo electrónico para que te informemos todo lo que sucede por aquí.