El Product Backlog
Product Backlog: definición y características básicas
El Product Backlog o Pila de Producto, uno de los artefactos dentro de Scrum, 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.
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”).
– 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”.
– El Product Backlog contiene al Product Goal u Objetivo de Producto, como compromiso asociado.
– 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.
¿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í.
¿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.
¿Qué hacer cuando el Product Backlog se vuelve inmanejable, debido a la gran cantidad de elementos?
Todos hemos visto Backlogs de producto con cientos 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.
Nuestro consejo es que, aquellos elementos que no hayan sido implementados en 6 meses o más, lo mejor es simplemente eliminarlos para no malgastar el tiempo.
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 o clasificar 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.