Product Backlog Building: PBB Canvas

¿Qué es el Product Backlog Building (PBB)?

El Product Backlog Building (PBB) es una técnica creada por Fabio Aguilar que busca transformar las ideas de negocio en elementos accionables dentro del marco de trabajo Scrum. Es una herramienta que facilita la construcción del Product Backlog, alineando los objetivos de negocio con las necesidades del producto. A través de PBB, los equipos de desarrollo pueden entender mejor los objetivos y descomponer las ideas en historias de usuario que aporten valor.

¿Cuáles son los objetivos del PBB?

• Ayuda a construir un Backlog de forma efectiva y Colaborativa.
• Construir una comprensión compartida del negocio del cliente, facilitando el descubrimiento y la comprensión del producto.
• Encuentre una manera de describir la experiencia del usuario con el producto.
• Facilitar el descubrimiento y redacción de Historias de Usuario.
• Priorizar expectativas y objetivos.
• Dar como resultado un Product Backlog totalmente alineado con el valor comercial del cliente.

¿Cómo funciona el PBB?

El PBB actúa como un puente entre las partes interesadas y el equipo de desarrollo, enfocándose en una comprensión profunda del producto desde una perspectiva de negocio. Su propósito es asegurar que los equipos de Scrum tengan una visión clara del producto, permitiendo que las historias de usuario estén directamente conectadas con los objetivos estratégicos de la empresa.

Pasos del Product Backlog Building (PBB Canvas)

• Definir el nombre del producto: Al definir el nombre del producto identificaremos con facilidad en caso de realizar varios proyectos, este corresponde al nombre de la solución o necesidad a resolver, podemos entrar un poco en contexto lo que va hacer y lo que no va hacer nuestro producto.

• Problemas: Comprender el estado actual, en esta etapa y de manera colaborativa, tendrá la misma comprensión del estado actual, resaltando los problemas o dolores. Es importante que conozca el problema antes de crear la solución.

• Expectativas: Comprender el estado deseado, en esta etapa es importante que compartas la misma comprensión del estado deseado, alineando tus expectativas con los problemas del estado actual. Donde quiero llegar con el producto, algunas veces las expectativas se componen como soluciones de los problemas pero en algunas otras ocasiones pueden surgir diferentes expectativas fuera de los problemas expuestos anteriormente.

• Personas: se debe mapear desde el punto de vista del usuario. Son las personas que van a interactuar con nuestro producto. De igual manera se debe mapear las actividades que estas personas ejecutaran dentro del contexto del producto. Averigüe quiénes son los usuarios, roles y personas involucradas en el producto y sepa qué hace y qué espera del producto.

• Funcionalidades: Se realiza una verificación y comparación con los problemas y expectativas que se han presentado del paso 2 y 3 con la finalidad de identificar las funcionalidades que van atender la mayor cantidad de problemas posibles o que ayudaran a alcanzar la mayor cantidad de expectativas. De esta manera tenemos un avance de priorización para el backlog de funcionalidades core, imprescindibles, tal vez si o talvez no.

• PBIs: Se aplica un refinamiento que esta incluido dentro del mismo PBB. 

Una vez se tiene el PBB listo para refinar, se revisan las funcionalidades para así poder crear las historias de usuario, ya dependerá del equipo y el Product Owner si las historias de usuario deberán realizarse con INVEST o si deben priorizarse con la técnica de MoSCoW, una vez determinado pasamos a lo que serán las tareas a realizar, todo esto de manera colaborativa. También para refinar están las técnicas de

• Step Maps, 
• Modelo ARO y, 
• Técnica COrg.

Escribir Historias de Usuario con PBB

Para escribir las historias de usuario con PBB seguimos la siguiente secuencia de la siguiente imagen:

Siguiendo el orden la historia de usuario quedaría: "Como" Ingeniero de Soporte TI, "Quiero" Crear un panel de control de seguimiento de clientes "Para" revisar el estado de incidencias del cliente.

Beneficios del Product Backlog Building (PBB)

• Claridad de Visión: El PBB asegura que todos los miembros del equipo y partes interesadas tengan una comprensión compartida de lo que se necesita lograr.
• Prioridades Claras: Ayuda a priorizar las funcionalidades según su impacto en el negocio, lo que optimiza el desarrollo.
• Foco en el Valor: Al vincular las historias de usuario con los objetivos de negocio, se asegura que el equipo trabaje en lo que realmente genera valor.
• Mejor Colaboración: Fomenta la comunicación y colaboración entre los equipos de desarrollo y las partes interesadas.

¿Por qué se debe hacer un PBB?

Hacer un PBB permite transformar las ideas de negocio abstractas en tareas concretas y priorizadas. Es crucial para evitar malentendidos y garantizar que el equipo de desarrollo trabaje en lo que realmente necesita el cliente o negocio. Además, ofrece una metodología clara para crear un backlog efectivo que guíe el trabajo del equipo Scrum y asegure que las entregas se realicen de manera coherente con los objetivos de negocio.

El Product Backlog Building (PBB) es, por tanto, una herramienta que optimiza el trabajo de los equipos ágiles, asegura la entrega de valor y conecta los objetivos empresariales con el desarrollo del producto.

si quieres saber más sobre este tema: https://www.productbacklogbuilding.com
Aquí dejare el PBB Canvas para que puedan descargarlo.