Eventos de Scrum. Reunión de planificación

13 de julio de 2015
http://cdn.exploringscrum.com/wp-content/uploads/2011/05/team.png

Al comenzar cada nuevo Sprint todo el equipo Scrum, incluídos Product Owner y Scrum Master pero no el cliente, se reúne en lo que se conoce como Planificación de Sprint. Se trata de un evento time-boxed cuya duración máxima no debe exceder las ocho horas para un Sprint de cuatro semanas y proporcionalmente menor si el Sprint es menor. El Scrum Master garantiza que el evento tenga lugar y que su duración no supere el tiempo máximo planificado.

En esta reunión se toman dos decisiones fundamentales:


¿Qué puede ser hecho en este Sprint?

El Product Owner es el encargado de seleccionar qué elementos del Product Backlog serán completados durante el Sprint.

Antes de empezar a seleccionar elementos se debe fijar cuál será el objetivo del Sprint, en consecuencia se seleccionarán aquellos elementos del Product Backlog coherentes con dicho objetivo.

El Product Owner decide y prioriza que items le gustaría ver completados al final del Sprint pero no decide cuáles son los que finalmente se desarrollarán, esta decisión concierne única y exclusivamente al equipo de desarrollo y es lo que se denomina compromiso de Sprint. Por ejemplo, el Product Owner puede preseleccionar diez elementos del Product Backlog y el equipo de desarrollo decidir que se puede comprometer con los ocho primeros pero el noveno es demasiado complejo como para poder ser incluído, no obstante el décimo es menor y sí podría ser incluído, en consecuencia, el equipo se compromete a completar los ocho primeros y el décimo.

Si el product Owner no estuviera de acuerdo podría hacer uso del triángulo calidad-velocidad-alcance, es decir, podría reducir el alcance de la novena tarea descomponiéndola en dos o más tareas menores de forma que si se pudiera incluir la parte más importante para el cliente.

El equipo de desarrollo hace uso de su velocidad estimada de desarrollo para determinar la cantidad de trabajo que se puede comprometer a entregar. Dicha estimación procede de la velocidad real alcanzada en Sprints anteriores, es decir, se calcula en base a resultados empíricos.

El conjunto de elementos del Product Backlog seleccionados para el Sprint recibe el nombre de Sprint Backlog sobre el cual también hablaremos en detalle posteriormente.

Es importante señalar que, además de las siguientes tareas del proyecto en el Product Backlog, se tendrán en cuenta de forma particular las tareas no completadas en el Sprint anterior, si bien es cierto que dichas tareas volverán al Backlog antes de empezar la reunión de planificación, tras la reunión de Revisión de Sprint, como veremos en su correspondiente apartado.

El Product Owner deberá explicar al equipo de desarrollo cada uno de los elementos seleccionados y resolver todas las dudas que éste pudiera tener.


¿Cómo se va a completar el trabajo seleccionado?

El Equipo de Desarrollo analiza los elementos del Product Backlog seleccionados y elabora un plan para llevarlos a cabo.

Dicho plan suele incluir dividir los ítems del Product Backlog, los cuales suelen ser expresados como Historias de Usuario (User Stories), en tareas técnicas, es decir, tareas de menor envergadura y mayor entidad a nivel técnico las cuales pueden ser llevadas a cabo por un único desarrollador. Además, se suelen organizar las tareas técnicas de forma que se eliminen dependencias o se puedan llevar a cabo primero las tareas con mayor cantidad de incertidumbre. Por ejemplo, si una de las historias de usuario requiere que se muestre un mensaje por pantalla cuando suceda una determinada acción y otra historia requiere que el usuario pueda tomar una decisión de verdadero o falso cuando suceda otra acción, el Equipo puede convenir en extraer una tarea técnica de ambas historias que consista en desarrollar un servicio proveedor de pop-ups, el cual deberá ser desarrollado antes de las dos tareas que lo utilizarán.

Otro caso podría ser que una de las historias suponga generar una aplicación nativa para un determinado sistema operativo mobile, tarea que no se ha llevado nunca a cabo con anterioridad por el equipo. Esta tarea concentra un alto grado de incertidumbre, la cual debe ser resuelta lo antes posible pues supone un elevado riesgo no controlado, por tanto el equipo de desarrollo extraerá una tarea técnica que consista en prototipar el desarrollo de un hola mundo como aplicación nativa.

Se debe tener cierto cuidado a la hora de reorganizar prioridades, pues podría darse el caso de que no se llegaran a completar todas las historias de usuario del Sprint y que las historias incompletas tuvieran mayor prioridad o importancia para el Product Owner que otras historias sí finalizadas, lo cual podría chocar con sus expectativas y las del cliente.

A lo largo del Sprint el equipo de desarrollo podría seguir descomponiendo las tareas en subtareas o modificando su plan de desarrollo a medida que fuera aprendiendo más sobre el trabajo a llevar a cabo.

Tanto durante la reunión de planificación como a lo largo del Sprint el Equipo de Desarrollo puede solicitar al Product Owner que clarifique algún detalle sobre las tareas. Si, al hacerlo, ambos se encontraran con que el trabajo es demasiado o demasiado poco para el Sprint podrían renegociar el alcance de forma que se garantizase la predictibilidad del Sprint.

Las Reuniones de Planificación suelen ser muy largas, hasta ocho horas de conversaciones técnicas. En muchas ocasiones he encontrado gran dificultad para mantener al Product Owner durante toda la duración de la reunión en la sala debido a lo inhumano del sacrificio para un perfil no técnico. Lo que suelo hacer es dividir la reunión de planificación en dos partes, la primera de aproximadamente un tercio del total es una explicación de las historias que se desea desarrollar. En ella el Product Owner explica cada historia de usuario y el Equipo de Desarrollo aclara sus dudas. En la segunda parte el Equipo de Desarrollo inicia el debate técnico, con las historias claras y frescas, y empieza la descomposición en tareas y la extracción de componentes y tareas de refactorización. Si se adopta esta medida es importante poder contar puntualmente con el Product Owner a mano para resolución de las dudas que puedan surgir.

Key Points
La reunión de planificación de Sprint es un evento time-boxed de hasta ocho horas de duración.
Durante la planificación se decide qué puede ser hecho en el Sprint y cómo se debe hacer.
Se establece un objetivo de Sprint que dé coherencia a las tareas seleccionadas.
El Product Owner prioriza las tareas pero el equipo de desarrollo decide cuales se van a hacer.
El Equipo estima cuántas tareas se completarán en base a su velocidad estimada de desarrollo.
El Sprint Backlog está formado por el conjunto de elementos seleccionados para completar durante el Sprint.
El Product Owner explica cada tarea que debe ser llevada a cabo.
El Equipo de desarrollo elabora un plan para llevar a cabo el incremento de Sprint.