He encontrado un artículo en el sitio Agile Commons dando consejos sobre cómo hacer mas ágiles las reuniones de planificación. El artículo, dividido en dos partes (Shorter Agile Meetings, Part 1: Iteration Planning e Shorter Agile Meetings, Part 2: Release Planning), da algunos buenos consejos, sobre todo esta parte:

Una reunión de planificación de la iteración se trata de acordar como equipo que podemos entregar una cierta cantidad de trabajo en la próxima iteración, y averiguar cómo haremos la implementción de esa labor. Para mí, la parte más importante del éxito de la reunión de planificación es que todo el equipo está de acuerdo en lo que se va ha construir, hasta los detallados criterios de aceptación para cada historia.

Esta parte de la reunión va mucho más rápido si usted ha hecho algo de lo siguiente:

1. El propietario del producto viene con una lista priorizada de historias de usuario que vayan a construirse
2. El equipo, o por lo menos unos pocos miembros, saben de que se trata la parte superior de la lista
3. El propietario del producto ha hecho un primer paso escribiendo los criterios de aceptación para las historias
4. El propietario del producto y un tester han discutido las historias y han añadido pruebas negativas
5. El líder de tecnología ha revisado las historias y los criterios de aceptación, y discutió de estos con el propietario del producto
6. El equipo tiene la lista de historias de unos pocos días antes, por lo que ha tenido algún tiempo para pensar acerca de la implementación

Aquí, en Locaweb observé algunos casos de pequeños desperdicios durante las reuniones de planificación. La identificación y eliminación de dichos desperdicios pueden acelerar las reuniones que duran más de lo necesario. He identificado algunas situaciones comunes:

Organización del backlog durante la reunión: He visto algunos casos en que el propietario del producto organiza el trabajo atrasado durante la reunión de planificación, con todo el equipo presente. Esta organización incluye dar prioridad a las historias hasta buscar mensajes de correo electrónico con las solicitudes de nuevas historias, pasando por tirar preguntas con solicitantes externos. Esta práctica acaba tomando un largo tiempo de la reunión y de todos los presentes, con lo que el foco se dispersa y el resultado de la planificación esté comprometido.

Discusiones muy detalladas: Es importante discutir los detalles necesarios, pero sólo los necesarios. En una reciente reunión, vi al equipo llamando a un especialista de otro equipo y abrir el Bloc de notas para listar todas las reglas de validación de un campo determinado. Pregunté si eso influenciaba en la estimación en sí, y descubrí que la historia ya estaba estimada. En la práctica, saber que hay 3, 5, o 13 reglas de validación es suficiente para estimar la historia, no hay necesidad de discutir la lista y cada una de ellas.

Discusiones de historias que no entraron en el sprint: En otra reunión recientemente noté una historia que, después de una breve discusión se decidió no incluirlo en el sprint - faltaba definir algunos detalles funcionales, y la prioridad no era tan alta. Antes de pasar a la siguiente historia, otra duda se suscitó. Con esto, el equipo pasó los próximos minutos discutiendo toda la historia de nuevo, no para decidir si debía entrar en el sprint, mas ahora definiendo los detalles para cuando ella entrara un sprint en el futuro.

Una solución sencilla

La solución que ayuda a minimizar estos problemas es simple: El PO enviará un correo electrónico listando las historias que se debatirán en el próximo sprint. El correo electrónico se deben enviar al equipo, para los solicitantes externos que están pidiendo historias, y para los POs de los otros equipos.

Esta práctica ayuda a:

• El propio PO debe organizar el Backlog con antelación;
• El equipo sabe las historias que se discutirán, y puede plantear algunos detalles que pueden ser importantes;
• Los solicitantes saben si sus historias se discutirán, y estan preparados si tienen que aclarar dudas;
• Los solicitantes saben que otras historias suyas no serán discutidas, y las pueden repriorizar si fuera necesario;
• Los POs de otros equipos saben si alguna historia puede tener un impacto en su producto, o si hay alguna dependencia que debe ser analizada;
• Divulgar a varias áreas lo que el equipo está haciendo.

En otras palabras, volviendo al artículo de Agile Commons, envias un mensaje de correo electrónico con antelación ayuda a resolver los temas 1, 2, 5 y 6 en la lista. Para los temas 3 y 4, una Definición de Hecho clara y precisa ayuda a resolverlos. Es decir, con dos simples pasos es posible reducir considerablemente el tiempo de la reunión de planificación.

Un detalle importante: Así como el Scrum Master es el responsable de la eliminación de impedimentos para puedan poner en peligro el progreso del sprint, él también es responsable de la eliminación de impedimentos que puedan poner en peligro el progreso de la reunión de planificación en sí. Empujando para el Pensamiento Lean, el valor de la reunión de planificación es tener un sprint planeado - cualquier cosa que no ayuda al equipo de lograr ese objetivo se considera desperdicio.

Basado en Como tornar reuniões mais ágeis