Un backlog, varios Product Owners: ¿cómo trabajar bien juntos?

En teoría, solo un Product Owner es responsable del backlog de un equipo Agile.

En la realidad, según la organización de la empresa, puede ocurrir que varios Product Owners compartan el mismo backlog y, por tanto, el mismo equipo.

Este puede ser el caso de una organización de tipo «centro de servicios», donde varios productos comparten el mismo equipo de desarrollo, con un Product Owner por producto.

Este inconveniente también surge cuando el producto tiene demasiada complejidad empresarial para que un solo Product Owner sea responsable de todo el producto, o cuando un solo Product Owner no tiene la capacidad de abastecer a todo el equipo.

En estas situaciones, ¿cómo se garantiza que los desarrolladores no tengan que hacer ellos mismos el trabajo de priorización? ¿Cómo se garantiza que se dé prioridad a las historias de usuario que aportan más valor?

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

El Kanban Ready

Lo ideal sería poder dividir el equipo para volver al gran principio de «1 Backlog = 1 Product Owner», pero en muchos casos no es posible: un equipo demasiado pequeño, depender de un perfil técnico, o la propia cultura de la empresa, son varios de los motivos por los que te puedes ver en esa situación.

Si tienes varios Product Owners trabajando en el mismo backlog, es probable que consideres al equipo de desarrollo como un cuello de botella. Probablemente, cada uno tenga sus propios objetivos, limitaciones y plazos.

Para evitar que se descubran los temas de tus compañeros durante la planificación del sprint y para evitar que esta sesión se convierta en una pelea a puñetazos, tendréis que daros la máxima visibilidad lo antes posible, durante toda la fase de maduración de las historias de usuario.

¿Y qué mejor manera que un Kanban para gestionar un proceso con varias personas?

El objetivo de tu Kanban debe ser llegar a una columna «Ready for dev», donde todas las historias de usuario deben estar priorizadas (sin importar qué Product Owner la haya escrito) y cumplir con la «Definition of Ready» de tu equipo.

Para construir las otras columnas de tu Kanban, inspírate en el proceso de escritura de tus historias de usuario. Puedes incluir la redacción (en Gherkin) de tus User Stories, la descripción de los criterios de aceptación, la creación de wireframes y maquetas... Todo depende de tu producto.

Cada carril o columna de tu Kanban representa la actividad de un Product Owner. Durante cada Scrum diario, como Product Owner tendrás un medio físico para presentar el progreso de tus actividades fuera del sprint actual. No solo podrás dar a todo el equipo una visión global de tu trabajo, sino que eso también debería fomentar las discusiones de coordinación entre los Product Owners.

Otra ventaja de este Kanban Ready es que permite regular el flujo de historias de usuario para asegurarte de que el equipo esté suficientemente abastecido, sin crear más historias de las que este puede llegar a manejar.

Esto significa que la capacidad de desarrollo del equipo determinará el número de historias de usuario que hay que escribir, el número de talleres de diseño y preparación que hay que organizar, etc.

Una vez determinado el «flujo» de tu equipo, puedes poner límites altos y bajos a cada una de tus columnas. Y si alguna vez un Product Owner se encuentra limitado en su trabajo de diseño como resultado de estas restricciones, siempre puede echar una mano con las pruebas, por ejemplo. A esto lo llamamos «swarming».

Gracias a este Kanban, deberías ser capaz de llegar a un consenso entre los Product Owners al final del proceso de maduración de las historias de usuario.

Sin embargo, si no se llega a ese esperado consenso, tendréis que decidir entre vosotros la importancia de las historias de usuario con técnicas que no se basan necesariamente tanto en el valor (una noción bastante específica de un producto determinado) como en el coste que implica cualquier retraso.

Si tuvieras que recordar una sola cosa, es que si te encuentras en esta situación, debes comunicarte a toda costa.

Aunque te ayude montar un Kanban para visualizar el flujo de maduración de las historias de usuario, recuerda que «las personas y sus interacciones son superiores a los procesos y las herramientas».

Es esencial que todos compartan la misma visión y que exista un gran espíritu de equipo. No dudes en crear una comunidad de práctica entre los Product Owners para reforzar vuestra coordinación y compartir vuestras experiencias.

Y tú, ¿te has enfrentado a esta situación? ¿Qué medidas ha tomado?

Para saber más: descarga el libro Agile Product Manager