El Product Backlog
Product Backlog: definición y características básicas
El Product Backlog o Pila de Producto es una lista ordenada de todo lo conocido que podría ser necesario en el producto y única fuente de requisitos y trabajo para el Equipo Scrum. Es uno de los artefactos dentro de Scrum, y cuyo compromiso asociado es el Product Goal o meta de producto.
Algunas de las consideraciones a tener en cuenta respecto al Product Backlog son:
– El Product Backlog nunca está completo, es dinámico, emergente; es un artefacto “vivo”, que evoluciona a medida que el producto y el entorno en el que se usa o la tecnología cambian.
– El Product Owner es el responsable de gestionar el Product Backlog. Esto implica aspectos como la creación y comunicación de sus elementos, asegurando que existe un entendimiento compartido por el resto de miembros del Equipo Scrum, así como su orden. Cuanto más arriba esté un elemento dentro del Product Backlog, más importante o prioritario es.
– El Product Owner puede delegar las actividades anteriores, si bien continuará siendo el responsable (“accountable”).
– El Product Backlog contiene al Product Goal u Objetivo de Producto, como compromiso asociado. O, dicho de otra manera, y esto es importante: el Product Backlog emerge para ayudarnos a conseguir un outcome (Product Goal), y no al revés.
– Los atributos de los elementos del Product Backlog, como la descripción, el orden y la estimación o tamaño, varían según el contexto o industria. En proyectos de software, a menudo incluyen descripciones de las pruebas o criterios de aceptación para que se consideren “Terminados”.
– Si varios Equipos Scrum trabajan en el mismo producto, se sigue utilizando un único Product Backlog.
¿Qué tipo de elementos puede contener el Product Backlog?
A pesar de su popularidad, las historias de usuario son solo un posible formato para enunciar los elementos del Product Backlog. La Guía Scrum ni siquiera menciona a las historias de usuario, puesto que se trata de una práctica -procedente del Extreme Programming- cuya utilización o no es decisión del Equipo Scrum. En el siguiente gráfico mostramos algunos de los elementos que pueden ser válidos en el Product Backlog, como historias de usuario, errores o bugs, requerimientos y especificaciones, requerimientos no funcionales, casos de uso, trabajo técnico, spikes, etc.
Y, no, crear un Product Backlog paralelo, como puede ser uno dedicado a bugs, no es una buena idea, tal y como comentábamos en este artículo.
Cómo ordenar los elementos del Product Backlog
Hay gente que intenta ordenar el Product Backlog usando alguna “formulita”, en un Excel. Esto no lo recomendamos.
Hasta que llegue el día en que la IA lo haga por nosotros, si es que llega. La experiencia e intuición del Product Manager y el equipo es lo que vale. Considerando factores como:
▶ Valor para el negocio
▶ Riesgo
▶ Coste / tamaño
▶ Dependencias
▶ Estrategia (Product Goal)
…
Técnicas como el modelo Kano o MoSCoW pueden ayudar a pensar. Pero no nos volvamos locos. Ordenar el Product Backlog tiene más de arte que de ciencia.
¿Cuándo se considera que un elemento del Product Backlog está ready (listo)?
Entendemos que un elemento del Product Backlog está ready para ser seleccionado en la Sprint Planning si puede ser terminado por el Equipo Scrum en un Sprint. O sea, su tamaño es tal que puede quedar hecho durante un Sprint. Para llegar al estado de ready, normalmente los elementos necesitarán de refinamiento previo.
Puedes leer más sobre la “definición de ready” aquí.
Los elementos del Product Backlog y la Definición de Terminado
Una vez que un elemento del Product Backlog es seleccionado para un determinado Sprint y cumple con la Definición de Hecho, nace un Incremento de Producto. La Definición de Hecho predica del Incremento y, por tanto, aplica a todos los elementos del Product Backlog en los que estemos trabajando. Los criterios de aceptación, en cambio, aluden a un elemento del Product Backlog en concreto; es decir, son las verificaciones o pruebas referidas a un elemento en particular, que también habrá de cumplir con la Definición de Hecho.
¿Qué es el refinamiento del Product Backlog?
El refinamiento del Product Backlog es el acto de revisar y añadir detalle a sus elementos, mediante descripciones, estimaciones, ordenación, etc. A través del refinamiento, descomponemos los elementos del Product Backlog en otros más precisos y de menor tamaño.
Habitualmente, los elementos del Product Backlog de menor prioridad, que probablemente no van a ser seleccionados durante Sprint Planning del próximo Sprint o el siguiente, van a tener un bajo nivel de refinamiento. Esto es, van a formularse de una forma más o menos vaga, sin un gran detalle. Lo contrario sería arriesgarse a invertir esfuerzo en refinar elementos del Product Backlog que quizás nunca lleguen a ser lo suficientemente importantes como para ser implementados. Añadimos estos elementos de “baja fidelidad” al Product Backlog simplemente a modo de recordatorio de esa conversación o refinamiento futuro.
En este artículo profundizamos sobre las actividades de refinamiento del Product Backlog.
Dimensionamiento de los elementos del Product Backlog
Scrum ni siquiera habla de ningún método de estimación en concreto. De hecho, no habla ya de estimar, sino de “dimensionar”. Por tanto, el Equipo deberá de encontrar aquellas técnicas que mejor le funcionen.
Lo que sí dice Scrum es que el dimensionamiento corre a cargo de los Desarrolladores (esto es, no del Product Owner o Scrum Master).
¿Qué hacer cuando el Product Backlog se vuelve inmanejable, debido a la gran cantidad de elementos?
Todos hemos visto Backlogs de producto con cientos o, incluso, miles de elementos. Llega un momento en el que, al ser tan extensos, su gestión se puede volver inabarcable, ante el ingente volumen de elementos antiguos y sin un orden claro. product
En estas situaciones, el Product Backlog deja de ser transparente. O sea, ni el Equipo y ni sus stakeholders van a poder entender su contenido.
2 consejos en este sentido:
- Eliminemos sin miedo los elementos del Product Backlog que no se hayan tocado en 6 meses. O en 3 meses. Si era importante, ya “cantará” por algún sitio.
- Cuanto menos entre en el Product Backlog, mejor. Cosas abstractas, ideas más o menos peregrinas o o de las que no estemos seguros, es mejor no introducirlas. Simplemente digamos que “no”, en lugar de seguir engordando el Product Backlog. Te dejo aquí un artículo sobre formas de decir que «no» como Product Owner.
Diferencias entre Product Backlog y Product Roadmap
En Scrum, el Product Backlog es el Product Roadmap. En la práctica, puede que el Product Owner encuentre útil agregar, clasificar o visualizar los elementos del Product Backlog de diferentes formas, para poder mostrar esa hoja de ruta o estrategia de producto a los stakeholders, y es entonces cuando creará algún documento a modo de Product Roadmap.
Herramientas para la gestión del Product Backlog
Hay múltiples herramientas de software para la gestión del Product Backlog. Mientras nos permitan mantener una lista ordena de elementos, prácticamente cualquier herramienta debe servirnos. Algunas de las más comunes utilizadas por equipos ágiles son Jira, Trello, Linear, Shortcut, Monday o Asana.