Qué es product backlog y guía para hacer uno con ejemplo

La creación de productos comienza con una idea, pero para crear algo especial hace falta contar con un equipo que trabaje con dedicación para poner esa idea en práctica. Sí, hasta los iPhone fueron un prototipo alguna vez, hasta que se abrieron camino y alcanzaron la popularidad que tienen gracias a que los desarrolló el equipo correcto. Cuando gestionas un equipo de desarrolladores con Scrum, mantener la organización es crucial para el éxito de los productos.

Entonces, ¿qué pueden hacer los equipos de Desarrollo para mantenerse organizados y cumplir con los objetivos? Listas de trabajos pendientes. El trabajo pendiente del producto o product backlog es, en esencia, una lista de tareas pendientes específicas. Si el equipo aplica una metodología ágil y tiene en cuenta los principios del Agile Manifesto, el product backlog servirá para dividir proyectos y determinar cuáles son las tareas más importantes. Esta definición puede cambiar algo cuando estamos trabajando con marcos ágiles a gran escala como SAFe.

Sigue leyendo para descubrir qué se incluye en el trabajo pendiente de los productos y cómo prepararlo para tu equipo.

¿Qué es un product backlog?

Llamamos product backlog a una lista de funciones y elementos, ordenados según las prioridades, que son necesarios para cumplir con los objetivos y las expectativas del proyecto. La regla general es desarrollar uno de estos conjuntos de trabajo pendiente del producto para cada producto y asignarle a un equipo ese trabajo pendiente en particular.

A veces, hay muchos conjuntos de product backlogs y varios equipos que trabajan en un solo producto más amplio. Tomemos el ejemplo de Adobe Creative Cloud. Adobe Creative Cloud es un producto que abarca a muchos otros de menor tamaño como Photoshop, Illustrator y After Effects. Cada uno de estos productos no tan grandes tendrían su propio product backlog y diferentes equipos designados para su desarrollo.

Los equipos que trabajan con metodologías ágiles dedican tiempo a crear productos y a hacer ajustes a medida que los proyectos avanzan. Dada la naturaleza de las metodologías ágiles, sabemos que las tareas del product backlog no son definitivas e inamovibles y que no todos los elementos se podrán finalizar. El equipo de Desarrollo deberá readaptar el trabajo pendiente del producto a medida que se prioricen las tareas necesarias.

¿Qué incluye el product backlog?

Por lo general, en el product backlog se incluyen las funciones, la reparación de errores, la deuda técnica y la adquisición del conocimiento. Estos elementos del trabajo pendiente del producto son los product backlogs items, elementos clave para poder realizar el product backlog.

1. Funciones (historias de los usuarios)

Cuando hablamos de función, también conocida como historia del usuario, en Scrum nos referimos a la función del producto que le resulta valiosa al usuario de ese producto. Estas funciones pueden ser complejas (en muchos casos, épicas) o pueden ser muy simples. Puede resultar útil elaborar un mapa de historias para que el equipo determine qué es lo que más necesita el usuario.

H3: 2. Reparación de errores

Las reparaciones de errores se explican por sí solas. El equipo que trabaja con Scrum debería ocuparse rápido de ellas para sostener la integridad del producto. Algunos errores pueden ser lo suficientemente importantes como para interrumpir el sprint en que se encuentra trabajando el equipo, mientras que otros pueden esperar hasta el siguiente sprint. Sin embargo, hay una regla general sobre los errores que indica que hay que tenerlos siempre al comienzo de la lista de trabajo pendiente del producto para que el equipo no los olvide.

3. Deuda técnica

Al igual que con las deudas financieras, cuando no se resuelve la deuda técnica, esta “acumula intereses”. Cuando los desarrolladores dejan trabajos técnicos al final de la lista de trabajo pendiente del producto, esos trabajos se acumulan y cada vez es más difícil cumplirlos. El equipo puede evitar la acumulación de la deuda técnica si se organiza y se ocupa de los trabajos técnicos de menor tamaño de manera progresiva y a diario.

4. Adquisición del conocimiento

La adquisición del conocimiento consiste en reunir información para cumplir con otras tareas del product backlog más adelante. Si el equipo tiene una función con la que no puede cumplir en caso de no reunir más información, entonces podrías crear una tarea para adquisición de conocimientos; algo como crear un prototipo, hacer un experimento o intentar con una prueba conceptual para obtener la información necesaria para el desarrollo de la función.

¿Cómo se hace un product backlog?

El concepto de “trabajo pendiente del producto” o pila de producto abarca más que una simple lista de pendientes. Puedes dividir tareas complejas en series de pasos y delegarlas a los miembros del equipo Scrum según corresponda. A continuación, compartimos los pasos para desarrollar con efectividad el trabajo pendiente del producto.

1. Crea una hoja de ruta del producto

La hoja de ruta del producto es el pilar del trabajo pendiente del producto. El equipo debe crear una hoja de ruta antes de preparar el product backlog porque la hoja de ruta es un plan de acción sobre cómo cambiará el producto a medida que se desarrolle. La hoja de ruta es la visión de largo plazo sobre el desarrollo del producto y también puede evolucionar.

2. Haz un listado con los elementos del product backlog

Con la hoja de ruta del producto en mente, el equipo puede empezar a enumerar los elementos del product backlog. Estos elementos pueden incluir acciones de prioridad alta o ideas más abstractas. Durante esta fase de la preparación del product backlog, también necesitarás comunicarte con todos los involucrados y escuchar las ideas de mejora para el producto que tengan para aportar. Con una plantilla de product backlog puede resultar mucho más fácil crear filas de tareas y después moverlas para reordenarlas.

3. Establece las prioridades

Después de que el equipo haya elaborado la lista de elementos o ítems del product backlog habrá que ordenarla y priorizar las tareas que son más importantes. Para identificar los elementos prioritarios piensa primero en los clientes y analiza cuáles son los que les aportarán más valor.

4. Actualiza todo con regularidad

Mientras el equipo avance con el product backlog recuerda que ese trabajo pendiente debe ser un documento vivo. Puedes agregar elementos continuamente y definir las prioridades una y otra vez, o readaptarlos a medida que se ocupen de cada uno de ellos.

Cómo priorizar los elementos del product backlog

Un componente esencial de la gestión del trabajo pendiente de un producto es determinar las prioridades de las tareas. Si eres el Scrum master deberías comprender profundamente qué funciones nuevas son las que pretenden ver en el producto los demás participantes involucrados en este trabajo. A continuación, compartimos algunas estrategias sobre cómo establecer las prioridades en una lista de elementos del product backlog.

Organiza las tareas por urgencia y por importancia

Cuando te centres en la readaptación del trabajo pendiente, prueba con organizar las tareas según la urgencia y la importancia. El equipo debe priorizar aquellos elementos del product backlog que mejoren las funcionalidades del producto y también la experiencia de los usuarios.

Ocúpate primero de las tareas complejas

El equipo se puede sentir inclinado a finalizar primero las tareas más simples para poder quitarlas del product backlog y acortar la lista, pero en realidad es una forma poco eficiente de gestionar los proyectos. El trabajo pendiente del producto seguirá creciendo, de modo que ocuparse primero de las tareas más complejas puede resultar más efectivo para el desarrollo del producto.

Finaliza las tareas en sprints específicos

Los equipos ágiles trabajan en sprints temporales específicos para finalizar los trabajos. Este método es muy efectivo para la productividad. Al final de cada sprint, el encargado del producto y cualquier otra persona que participe en el desarrollo podrá asistir a una revisión del sprint contigo y el equipo de Desarrollo para garantizar que todo esté encaminado. Las tareas que forman parte de cada sprint forman parte del sprint backlog.

Comunícate con el equipo

La comunicación entre los miembros del equipo es crucial para el proceso de priorización del product backlog Para ordenar correctamente el trabajo pendiente y finalizar los elementos en un plazo razonable, tienes que trabajar junto con tu equipo y seguir la guía de Scrum.

Ejemplo de product backlog

Los trabajos pendientes de productos pueden ser diferentes según el proyecto, incluso algunos comienzan con una épica. Una épica es un problema global que pretendes resolver para un cliente. A continuación, compartimos un ejemplo:

Épica: Como gerente de Marketing, quiero un sistema que me permita entregar contenido de calidad a mis lectores.

Esta épica podría tener como resultado varias funciones que abarquen desde cómo genera contenido un usuario en el sistema nuevo a cómo lo edita y lo comparte con otros equipos. Para continuar con nuestro ejemplo de trabajo pendiente del producto, podemos dividir la épica en historias de usuarios más específicas.

Historia 1: Como creador de contenido, quiero un sistema de gestión de contenidos que me permita crear contenido para poder informar a los clientes sobre nuestros productos.

Historia 2: Como editor, quiero un sistema de gestión de contenidos que me permita revisar el contenido antes de publicarlo para poder garantizar que esté bien escrito y optimizarlo para las búsquedas.

El product owner, el Scrum master y el equipo de Desarrollo determinarán las funciones que debería incluir el producto a partir de las historias de los usuarios y establecerán las prioridades según la importancia de cada historia.

Funciones que debería incluir el producto según la historia 1:

1. Iniciar sesión (en el sistema de gestión de contenidos)

2. Crear contenido

3. Editar una página de contenido

4. Guardar cambios

5. Asignar contenido a un editor para su revisión

Como product owner, usarás la épica como orientación para la hoja de ruta del producto y para los elementos de la lista de trabajo pendiente. Como puedes ver en este ejemplo, una épica puede dividirse en muchas historias de usuarios y funciones del producto.

¿Por qué el product backlog puede ser útil para el equipo?

El product backlog sirve para que el equipo funcione como un motor bien aceitado, ya que mejora la organización y la colaboración del grupo. Se vuelve una herramienta central de comunicación y ayuda a mantener a todos alineados con respecto a los objetivos y las expectativas comunes.

Dado que todo el trabajo que se lleva a cabo para un producto fluye a través del product backlog, este trabajo es el que brinda las bases para la planificación de la iteración. Como en tu equipo se establecen las prioridades de las tareas según la orientación del product owner, también será este último quien determine cuánto trabajo pueden incluir en un bloque específico de tiempo. Estos bloques de tiempo se denominan iteraciones o sprints. 

El product backlog también favorece el desarrollo de equipos que aplican metodologías ágiles porque incentivan los ambientes laborales flexibles y, a la vez, productivos. Las tareas enumeradas en el trabajo pendiente del producto no son definitivas e inamovibles. El equipo puede ordenarlas según la importancia antes de elegir de qué tareas ocuparse primero.

Sprint backlog vs. product backlog

Los sprint backlogs y los product backlogs son muy similares en cuanto a lo que contienen. Los de sprints son un subconjunto de los del producto, pero se trabaja con ellos específicamente durante los sprints.

El product owner tiene el control sobre el trabajo pendiente de ese producto porque abarca al producto entero de principio a fin. El equipo de Desarrollo es responsable del trabajo pendiente de cada sprint, porque estas listas menos extensas de pendientes, extraídas del trabajo pendiente del producto, se deben finalizar dentro de períodos determinados.

El sprint backlog depende del trabajo pendiente del producto y termina cuando también termina el sprint. Para el trabajo pendiente de un sprint también hay un objetivo propio de ese sprint que se desarrolla durante la planificación de sprints. El trabajo pendiente del producto se centra en el objetivo global del producto y las tareas se priorizan en base a ese objetivo.

El product backlog es más flexible que el de los sprints y puede variar según las necesidades del cliente. Además, el product backlog permanece hasta que el producto se desarrolla por completo y hay que mantenerlo siempre actualizado.

Volvamos al ejemplo del product backlog. También podemos presentar un ejemplo de sprint backlog. Durante el desarrollo de un accesorio para autos, destinado a ayudar a alguien a manejar solamente con las manos, una de las tareas del trabajo pendiente del producto consistía en crear un prototipo del accesorio para autos. Este prototipo podía transformarse en un sprint porque para desarrollarlo se necesitaba un subconjunto de tareas.

En el sprint backlog para el prototipo del accesorio para autos se pueden encontrar los siguientes elementos:

1. Crear un esquema conceptual

2. Desarrollar un prototipo virtual

3. Construir un prototipo físico

4. Ubicar un fabricante que construya el prototipo

Estos elementos del sprint backlog también estarían dentro del product backlog. Pero al separarlos dentro de su propio sprint, los desarrolladores pueden cumplir con el proceso Scrum a medida que finalizan las tareas y así crear el prototipo rápido.

Registra los avances en el product backlog

Cuando tienes el trabajo pendiente del producto bien organizado es mucho más fácil hacer que tu producto alcance la línea de llegada. Una aplicación en la nube como Asana puede ayudarte a gestionar proyectos con metodologías ágiles de la manera más eficiente que existe con un software moderno para Scrum.