Para hablar del backlog preview, recordemos un artículo (en francés, por lo pronto) sobre la relación entre los Product Owners y los desarrolladores, Clément destacó la importancia de involucrar a los desarrolladores en la visión y el diseño del producto.
Cierto es que el ritmo del Scrum y su sucesión de sprints, así como la división en historias de usuario independientes, puede conducir rápidamente a una mala organización; un sistema en el que los Product Owners generan a su ritmo un flujo continuo de historias de usuario, y los desarrolladores se limitan a estimarlas y desarrollarlas, sin aportar nada ni tener una visión de conjunto.
Yo mismo me encontré con este problema en uno de mis proyectos.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Además de comunicar al equipo un objetivo general y una visión de producto (algo, sin duda, esencial), lo difícil fue conseguir que los equipos de desarrollo tuvieran la opción de visualizar en todo momento las funcionalidades o evoluciones que había que entregar durante los dos siguientes sprints.
Además, también queríamos recabar las opiniones de los desarrolladores con más experiencia para escuchar sus ideas y adaptar nuestras historias a las limitaciones técnicas esperadas.
Existe la posibilidad de aplicar distintos enfoques complementarios para resolver este problema de visibilidad «a medio plazo» e involucrar a los desarrolladores desde la fase de diseño de la historia.
Transparencia total con el backlog
En el proyecto, nuestro backlog estaba completamente abierto a todo el equipo, con acceso desde Jira pero también como una gestión visual en una pared específica para ello.
Como Product Owners, también procurábamos comentar durante las reuniones diarias los temas en los que estábamos trabajando, las impresiones que compartían los clientes, o los grandes cambios que cabía esperar en cuanto a la orientación de los productos.
No obstante, el hecho de que toda esta información sea accesible no significa que se vaya a leer.
Un equipo de desarrollo en pleno sprint rara vez dedica tiempo a leer por simple curiosidad las especificaciones de una historia de usuario que no se desarrollará hasta dentro de uno o dos meses, y mucho menos propondrá modificaciones o sugerencias.
Por eso, es preferible organizar una reunión periódica en la que todo el equipo se reúna para hablar del backlog.
Sesiones de estimación del backlog
Una opción consiste en organizar sesiones periódicas de estimación de historias, ya sean breves —por ejemplo, mediante el póker de planificación o talleres eXtreme— o más exhaustivas.
De esta manera, nos aseguramos de contar con una reserva de historias estimadas y damos al equipo visibilidad (de alto grado) sobre las próximas características de la aplicación.
Esta forma de proceder es útil para el Product Owner, porque le permite planificar mejor los futuros sprints y anticipar la reescritura de historias de usuario que se consideren demasiado complejas o importantes. Ahora bien, plantea varios problemas.
En primer lugar, esos talleres son relativamente frecuentes, por lo que no deberían durar demasiado: las historias se describen a grandes rasgos, los suficientes para una estimación rápida, pero no en tanto detalle como para discutir el trasfondo o recabar ideas.
Después, nos dimos cuenta de que estimar el backlog por adelantado en realidad no ahorraba demasiado tiempo. Por supuesto, eso no es parte del objetivo principal, pero para presentar cada historia de usuario dos veces hay que invertir mucho tiempo.
Unas semanas más tarde, cuando llegó el momento de construir el sprint, todo el mundo se había olvidado de lo se había comentado sobre la historia y los motivos de la estimación inicial; entre tanto, puede que la historia se hubiera modificado o que algunos desarrolladores no hubieran estado en la sesión de estimación y acabaran descubriendo la historia en la planificación del sprint.
Sesiones del backlog preview
Al final, decidimos organizar sesiones periódicas de intercambios sobre las historias, que bautizamos como vista previa del backlog o Backlog Preview.
Estas reuniones, a menudo organizadas justo después de la reunión de primera hora o Stand Up diario, no debían durar más de 10 o 15 minutos, y se limitaban a una historia de usuario por sesión. Seleccionamos las historias dando prioridad a:
- Las funcionalidades "estratégicas" que representan grandes cambios en el producto: nuevo panel funcional, rediseño de los roles de los usuarios...
- Las historias de usuario para las que considerábamos varias soluciones o implementaciones posibles, con la necesidad de evaluar la complejidad de cada una para poder tomar una decisión.
- Las historias de usuario aún en borrador para las que necesitábamos nuevas ideas o asesoramiento externo.
- Las historias de usuario que intuíamos que plantearían grandes retos técnicos.
- Por último, las historias de usuario con un posible impacto en las funcionalidades que se estaban desarrollando en el sprint.
El propósito de estas sesiones no era estimar las historias, sino presentar al desarrollador lo que teníamos en mente para el futuro del producto y conocer su opinión no solo sobre la viabilidad técnica, sino también sobre la UX y las funcionalidades.
Elegir las historias relacionadas con las funcionalidades del sprint actual también permitió en ocasiones anticipar futuras necesidades funcionales de la arquitectura o los desarrollos actuales.
Balance
Celebramos esas reuniones cuando era necesario, normalmente una o dos veces a la semana.
Hubiera sido preferible dedicarles un horario fijo, pues a la larga una franja horaria tan laxa acaba generando dispersión y una desaparición gradual de las reuniones de Backlog Preview.
Sin embargo, a día de hoy el concepto de reunión colaborativa sobre los relatos en una etapa bastante temprana de desarrollo todavía parece pertinente, pues ofrece la posibilidad de que cada miembro del equipo aporte ideas según su experiencia (técnica, UX, funcional).
Y tú, ¿cómo involucras a tus desarrolladores en la creación de las historias y comunicas tu backlog a medio plazo?
Para saber más: descarga el libro Agile Product Management
Foto de Kaleidico en Unsplash
