Reunión de planificación del Sprint

El Sprint comienza con esta reunión, donde se pretende concretar lo suficiente el alcance del mismo, y a partir de ese momento comprometerse con el mismo sin perder el foco. Por ello hay que responder a dos preguntas fundamentales:

¿Qué se puede terminar durante el sprint?

Debo recordar aquí que terminado significa idealmente listo para entregar al usuario. El entregable terminado durante un sprint concreto se denomina incremento de producto. Para poder responder a la pregunta anterior, lo primero que hay que conocer el histórico de entregas en sprints anteriores, sobre todo en los más recientes, para estimar la velocidad del equipo. También hay que tener en cuenta la capacidad de desarrollo prevista del equipo. Esta está condicionada, por ejemplo, por posibles vacaciones y reuniones, y especialmente por trabajar en multiproyectos, lo que anticipo que se desaconseja.

Como es lógico, en los primeros sprints falta información para ofrecer una estimación fundada; pero la idea es que, transcurridos varios, el equipo alcance una velocidad de crucero, que se puede medir y sirve para proyectar en los siguientes.

Por otro lado tiene que estar muy bien formalizada y priorizada la lista de producto, aunque todavía no he comentado sobre la misma. En este punto basta saber que es el Product Owner quien la define, y que prioriza las funcionalidades pendientes que más valor aportarán al negocio. No obstante es el Development Team quien decide cuántos de estos elementos, por orden de prioridad, puede terminar durante el sprint.

Algunos matices

Podemos pensar que esta parte de la reunión se alarga mucho, pero se supone que en sprints anteriores se ha celebrado otra reunión específica para ir detallando y estimando la lista de producto. De esta forma la preselección se puede hacer bastante rápida.

La estimación que realiza el equipo de desarrollo suele basarse en puntos asignados a cada elemento de la lista, y que tiene en cuenta la complejidad del desarrollo, posibles riesgos, etc. En función del histórico del proyecto, se puede establecer una media de puntos entregados por sprint, y así se precisa mejor cuántos elementos de la lista son abordables en el actual.

Hay otra matización importante de este apartado, y es que se recomienda formular un objetivo concreto del sprint. Es decir, no se trata de ir implementando elementos deslavazados, sino que el equipo debe comprender cómo esos elementos conjuntamente proporcionan valor al negocio, y por qué son más prioritarios que otros, algo que debe aclarar el Product Owner.

¿Cómo se conseguirá completar el trabajo seleccionado?

Una vez preseleccionados los elementos de la lista de producto más prioritarios, es necesario establecer un plan de desarrollo o implementación. Esto suele requerir que el Product Owner aclare detalles funcionales que hasta el momento no eran conocidos. También es probable que el equipo de desarrollo ajuste sus estimaciones de puntos a medida que dispone de más información, o por ejemplo advierta algún riesgo que no se había considerado inicialmente. También se pueden incluir elementos menos prioritarios, pero que, por motivos técnicos, o porque convienen al objetivo, se podrían abordar en este sprint. Con todo ello se espera generar la lista de elementos pendientes para el sprint en curso, incluyendo el plan de trabajo asociado.

En este punto, el plan es todavía un tanto genérico, y aborda aspectos como las tecnologías a usar, tareas de alto nivel a llevar a cabo, medidas de calidad o de terminación del trabajo, y cómo se espera dividir el trabajo entre las diferentes personas. Es importante que de la reunión se salga con una secuenciación lógica y completa de todo el sprint, aunque sea de alto nivel.

Un plan no puede ser estático

El plan es competencia directa del equipo de desarrollo. Lejos de ser algo estático (fijado por esta reunión), va evolucionando y entrando a mayor nivel de detalle a lo largo del sprint, y está presente en el resto de reuniones. Más que con un diagrama de Gantt, el grado de avance se visualiza con esos post-its de colores que a todos nos vienen a la mente cuando se habla de agilidad.

Nota personal: El diagrama de Gantt no tiene nada de malo en las prácticas ágiles, lo malo viene cuando se entra en demasiado nivel de detalle de tareas, sabiendo que va a haber cambios diarios.

Ya intuimos que es probable tener que renegociar sobre los elementos de la lista de producto preseleccionados al completar la primera pregunta, algo característico de la agilidad, siempre que no vaya en contra del objetivo. Esto ocurre en la planificación, pero también en el día a día del sprint, donde podemos interpretar que existe cierta replanificación. Y también muy natural para los proyectos de Analítica, Big Data y Business Intelligence, donde los diferentes interesados tienen que ofrecer feedbacks frecuentes de lo que necesitan y de lo que se va entregando. Y donde se van descubriendo aspectos de la calidad y disponibilidad del dato que requieren adaptar las tareas, o lanzar procesos que duran horas.

Conclusiones

Podemos apreciar cómo el equipo de desarrollo gana competencias de gestión respecto a la manera tradicional. Pero igualmente crece su responsabilidad ante el resto de interesados. Por ejemplo, si el equipo de desarrollo es muy conservador a la hora de realizar estimaciones, habrá alguien en la organización que pida explicaciones por ello, empezando por el Product Owner.

Sin duda, la dirección de la empresa va a esperar cada vez mayor velocidad percibida, y también hay que demostrar mejoras tangibles frente a las metodologías predictivas. En concreto, volviendo a la analítica, el Big Data y el Business Intelligence, lo primero que hay que evaluar es si los usuarios están usando nuestros productos. Y, lo segundo, si el ritmo de entregas es el adecuado (aunque siempre hay usuarios con un afán desmedido de nuevas funcionalidades, y es el Product Owner quien tiene que gestionarlo).

Algunos errores comunes de interpretación:

En último extremo el compromiso del sprint no es una lista de elementos seleccionados de la lista del producto, sino el objetivo fijado en la primera parte de la reunión. El objetivo ayuda a centrar el foco, evitando cambios durante el sprint que claramente pongan el riesgo el mismo. También afianza la idea de colaboración en equipo para conseguir un resultado conjunto. Y a la vez permite cierta flexibilidad sobre elementos concretos, que pueden entrar o salir de la lista de elementos pendientes del Sprint.

Si se quiere contar con flexibilidad ante cambios frecuentes, las renegociaciones también son frecuentes. Aquí es de utilidad el Scrum Master para ayudar a vencer momentos de bloqueo, o para evitar que una parte someta a la otra sistemáticamente.

A la hora de profundizar en los requisitos del producto, es conveniente que el equipo técnico pueda reunirse directamente con otros interesados de negocio. Si hablamos de proyectos de analítica, pasa a ser crítico. El error es pensar que el Product Owner debe conocer todos y cada uno de los requisitos de negocio, y aislar al equipo técnico del resto de la empresa. En realidad la figura es más de coordinador y facilitador de toma de requisitos (por ello se recomienda que sea una única persona).

Sí que debe vigilar que se priorizan los de mayor valor, y resolver conflictos de intereses contrapuestos de los stakeholders, para que el producto sea coherente. También debe evitar cambios en medio del sprint que pongan en riesgo el objetivo, como ya hemos visto. Seguramente un Product Owner se acerca más a la figura clásica de jefe de proyecto de negocio, que el propio Scrum Master, algo que también genera cierta confusión cuando se utiliza Scrum por primera vez.

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.