Si hay varios equipos… ¿Cuántos Product Backlog debería haber?

Vamos con este tema, que últimamente me estoy encontrando bastantes líos con esto, con lo de si deberíamos tener un único Product Backlog para todos los equipos o varios Product Backlog.

Vamos primero con la teoría, a ver que se dice por ahí, que, como siempre te digo, lo que te cuento por aquí siempre son cosas estudiadas y probadas (nunca te cuento nada que no haya usado), así que vamos primero con las «estudiadas».

Empecemos por la guía de Scrum, que no deja muy claro si, habiendo varios equipos, deberían compartir un único Product Backlog, aunque comenta que el Product Backlog:

«It is the single source of work undertaken by the Scrum Team» (vamos, que el Product Backlog es la única fuente de trabajo para el equipo, que un equipo no tenga varios)

Vamos a revisar más cosas dignas de leer, por ejemplo, el libro «A Scrum book» (que co-firma el co-creador de Scrum, Jeff Sutherland, al que entrevisté hace años), donde hay algo más de información:

«It is impossible to easily see the order of delivery if each team keeps its own list. Therefore: For each product, create a single ordered list called the Product Backlog». (Es imposible ver fácilmente el orden de entrega si cada equipo tiene su propia lista. Por lo tanto: Para cada producto, cree una lista ordenada única llamada Product Backlog)

«…and each Development Team works from only a single Product Backlog. The Product Backlog drives all Development Team work—developers respond to no other source of work requests external to their team» (…y cada equipo de desarrollo trabaja un único Product Backlog. El Product Backlog dirige todo el trabajo del Equipo de Desarrollo: los desarrolladores no responden a ninguna otra fuente de solicitudes de trabajo externas a su equipo.)

«Having a single Product Backlog per product can put an end to the thrashing that can occur between groups with differences in perspective within a company». (Tener un solo Product Backlog por producto puede poner fin al conflicto que puede ocurrir cuando hay grupos con diferencias de perspectiva dentro de una empresa.)

En resumen, que para varios equipos… un único Product Backlog (pero espera, que esto aún no ha acabado).

Vamos con la última, que hay muchas y tampoco es cuestión de extender el post más de lo necesario, otra fuente mas, LeSS, que dice que…

«Multiple teams building a single product work from a single Product Backlog that defines all of the work to be done on the product. They do not each have their own Product Backlog. Product Backlog Items are not pre-assigned to the teams» (Varios equipos que crean un solo producto trabajan a partir de un solo Product Backlog que define todo el trabajo que se debe realizar en el producto. No tiene cada uno su propio Product Backlog. Los elementos de la cartera de productos no están pre-asignados a los equipos).

Y creo que ya no hace falta citar más referencias (que las hay) para concluir que la teoría dice… un único Product Backlog por equipo, pero… ¿siempre? ¿así de fácil? Claro que no, porque la teoría es la teoría, ahora vamos con la vida en la trinchera…

Las excepciones a la regla de un producto… un único product backlog

Como hemos visto, la regla, por defecto (y en muchas ocasiones sin mojarse mucho), es un único Product Backlog por producto, pero la realidad, a veces, es más complicada como para poder resolverla con reglas inamovibles (Shu-Ha-Ri).

Dicho así, la regla es bastante genérica y, además, tenemos el GRAN PROBLEMA de qué definir exactamente qué es un producto, algo que es ambiguo y que está bajo centenares de casuísticas (productos, subproductos, suite de productos, funcionalidades que están en diferentes productos, etc.).

Como comenta Essential Scrum, podemos tener productos muy grandes, incluso productos en los que trabajen decenas de equipos, lo que nos podría llevar a tener que manejar, siendo estrictos a la regla anterior, un único Product Backlog muy grande… y eso conlleva mucho desperdicio (ya lo hablamos en ¿Tamaño del Product Backlog? Mantenlo a dieta y en aplicando el método Marie Kondo a la limpieza de Jiras).

¿Y qué sucedería si, por el tamaño, hubiera muchos Product Owner? ¿Todos gestionarían ese único Product Backlog?

Pero es que incluso podríamos tener equipos que crean funcionalidad… para varios productos diferentes, entonces… ¿dónde estaría su Product Backlog? Sabiendo que un equipo sólo tiene un Product Backlog.  

Ya te aviso que yo he llegado a ver más de 3 product Owner en un único Product Backlog gigante para varios equipos, te puedes imaginar el caos que suponían los Planning, así que, veamos opciones…

Cuando es más sensato y menos Oscuro tener varios Product Backlog

Pues, como es obvio, cuando mantener un único Product Backlog genera más problemas de gestión (desperdicio) que tener varios, lógicamente, y eso suele suceder, principalmente en dos situaciones cuando…

Tenemos muchos equipos

Si tenemos muchos equipos, esto nos llevaría un único Product Backlog muy grande y difícil de manejar… entonces plantéate crear una jerarquía (pequeña, típicamente dos niveles) de Product Backlogs, teniendo cada equipo (o grupos de equipos afines) su Product Backlog que puede derivar de un Product Backlog superior (si lo ves necesario). 

Equipos muy diferentes, que hacen items diferentes

Equipos muy heterogéneos nos suele llevar a un Product Backlog en el que los items están claramente pre-asignadas a un equipo y es muy difícil que los haga cualquier otro equipo. Si esto pasa, entonces suelen empezar las priorizaciones raras, en vez de por valor, por asignaciones a equipos.

Si tienes ese tipo de backlog en el que se sabe claramente, de antemano, qué equipo va a hacer cada item o Historia de Usuario… plantearos tener un Product Backlog por equipo.

Así que, si las Historias (o los Items) son muy diferentes, si los equipos son muy diferentes, si miden su velocidad de manera muy diferente, si todo es muy diferente, es un poco lío mantener todo en un mismo Product Backlog. 

En cualquier caso, si mantienes un único Product Backlog para varios equipos

Si al final decidís mantener un único Product Backlog, pues ya sabes, más cuidado aún si cabe en que esté bien ordenado por valor antes del Planning, que estén bien los items, que sea lo más pequeño posible. 

Es muy recomendable que aseguréis buenas reuniones de refinamiento, buenas reuniones de revisión con los Stakeholders, que el lío de mantener el Product Backlog afecte lo mínimo al equipo y que en los Planning, los repartos de items sean lo mas rápidos y con menos desperdicio (porque el Product Backlog llega como debe de llegar)

Terminando

Ya te digo que he visto de todo, de todas las combinaciones, tanto las que funcionaban, como las que eran un caos.

Como te contaba, desde ver más de 3 product Owner en un único Product Backlog gigante para varios equipos… un caos, hasta, por ejemplo, los equipos Mr. NoBody que tienen un único Product Backlog compartido y en los Planning se reparten los Items (que pueden hacer cualquiera de esos equipos).

Ya sabes, experimenta y no te quedes en lo que dice un framework.

Ah, cosas para leer sobre este tema, pues tienes esta referencia, por ejemplo, del libro Essential Scrum.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba