Hay un solo Product Backlog para un producto

Hay un solo Product Backlog para un producto

El propósito del Product Backlog es representar todo el trabajo que el Equipo Scrum necesita hacer para mejorar la entrega de valor en el producto.

El Product Backlog tiene un objetivo de producto que provee dirección a largo plazo para el producto.

El Product Backlog puede ser considerado como una lista de problemas acerca del cliente que el equipo debe resolver o una lista de hipótesis para entregar valor que el equipo debe validar.

El Product Backlog es «emergente», lo que significa que crece, se reduce y evoluciona con el tiempo. No es un artefacto estático, sino que se actualiza con frecuencia en función de la información descubierta de los clientes y el mercado.

El Product Backlog es un medio para fomentar el trabajo del equipo. Hay un único Product Backlog por producto. Esto significa que no hay otros Backlogs, por ejemplo, para defectos o para el trabajo de UX o de Arquitectura. Todo vive en el mismo Product Backlog. Además, si varios equipos de Scrum están trabajando en el mismo producto, utilizan el mismo backlog.

El Product Backlog está Ordenado por valor:El Product Owner ordena el Product Backlog y puede tomar en cuenta diversos factores.

Cuando las organizaciones inician la adopción de Scrum pueden comenzar donde están y allí se encuentran muchas veces equipos solamente dedicados a crear APIs o servicios, equipos dedicados exclusivamente a realizar descubrimiento o arquitectura, etc. Todos estos equipos deberían estructurarse de una manera que se enfoquen en el objetivo de entregar valor a través de la entrega frecuente de producto. Por si solos cada equipo no puede entregar valor al usuario a través de un incremento usable. Todos equipos trabajan sobre un solo Product Backlog del Producto.

Recomendaciones:

1. Evitar Product Backlog separados por equipos técnicos como, por ejemplo, de servicios, o backend, etc. Si hay varios equipos brindando el soporte de capacidades para entregar valor entonces deben integrar frecuentemente su trabajo hacia un mismo objetivo de Producto y un solo Product Backlog.
2. Definir Criterios de Terminado que ayuden a obtener un incremento de producto potencialmente liberable al mercado. Bajo este concepto los equipos de solo descubrimiento o solamente servicio necesitan organizarse con otros equipos para entregar producto frecuentemente en cada Sprint y aprender de los clientes.
3. Iniciar la organización de los equipos desde una visión, objetivo de producto y el valor. La estructura de los equipos puede organizarse en un modelo de escalamiento usando Nexus de Scrum.org basado en Scrum enfocados en un Objetivo de Nexus, seguido del objetivo de Producto y objetivos de Sprints alineados y todos colaborando sobre un solo Product Backlog.
4. Establecer un proceso de inspección frecuente para identificar y solucionar las dependencias entre los equipos de manera oportuna, reduciendo el riesgo de no entregar producto. La gestión de dependencias es clave para facilitar la integración frecuente. El uso de Nexus de Scrum.org puede ayudar a través de los eventos de escalamiento y la gestión de dependencias a través de un tablero de dependencias.
5. Evitar los equipos de solamente descubrimiento, integrar esas capacidades en los equipos Scrum.
6. Establecer una arquitectura que brinde soporte de servicios desacoplados basados en microservicios para promover un evolución del producto de manera incremental reduciendo las dependencias.